البحث في الموقع

يستخدم النّاس المواقع والتّطبيقات لأسباب مُختلفة، فإن صمّمت لسلوك غير ما تريده، فلن تحصل على النّتائج الّتي تريدها. سنتعلّم اليوم الأساليب المُختلفة للنّاس في الاطّلاع على التّصميم: التّصفّح، والبحث، والاكتشاف. قد تعني هذه الكلمات أمورًا مختلفة في سياقات مُختلفة، ولهذا سنوضّح المقصود منها في هذا الدّرس: التصفّح يعني إلقاء نظرة "بحثًا عن أفكار"، كأن تذهب إلى متجر بلا هدف، وتخرج حاملًا بعض المُنتجات غير الضّروريّة. البحث هو أن تذهب إلى المتجر لشراء غرض مُحدّد. الاكتشاف هو أن تذهب إلى المتجر لشراء ذاك الغرض، وتعود به مع غرض آخر أعجبك. فهرس سلسلة مدخل إلى تجربة المستخدم: مدخل إلى تجربة المستخدم User Experience فهم ودراسة المستخدمين في مجال تجربة المستخدم دراسة الشريحة المستهدفة في مجال تجربة المستخدم كيفية التصميم للأجهزة المختلفة هندسة المعلومات في تجربة المستخدم تعرف على أنماط التصميم في مجال تجربة المستخدم أشياء لا يمكن اعتبارها رسوما تخطيطية (Wireframes) في مجال تجربة المستخدم تعرف على الرسوم التخطيطية (Wireframes) في مجال تجربة المستخدم مفهوم الثقل المرئي (Visual Weight) والألوان في مجال تجربة المستخدم التكرار ومخالفة الأنماط في مجال تجربة المستخدم المحاذاة والقرب في مجال تجربة المستخدم تعرف على أساليب مسح الواجهة والتراتب المرئي في مجال تجربة المستخدم أساليب الإطلاع في مجال تجربة المستخدم: التصفح، البحث والاكتشاف (هذا الدرس) تصميم هيكل صفحة الويب والعناصر الأساسية في مجال تجربة المستخدم الأزرار، النماذج والدعوات إلى الإجراء في مجال تجربة المستخدم استخدام علم النفس في مجال تجربة المستخدم لتكييف المستخدم وإقناعه كيف تغير الخبرة من تجربة المستخدم؟ تصميم تجربة المستخدم من خلال بيانات وإحصائيات المستخدمين تعرف على أنواع المخططات الإحصائية في مجال تجربة المستخدم اختبارات أ/ب (A/B Test) في مجال تجربة المستخدم التصفح عندما تزور متجرًا إلكترونيًّا لمجرّد أنّ منتجاتهم تبدو مغرية أو لأنّك تتابع "الموضة"، أو لأنّك تحلم بذلك اليوم الّذي ستقتني فيه تلك الحقيبة الثّمينة الّتي ستجعلك إنسانًا أفضل (!)، فأنت تتصفّح. المُستخدم المُتصفّح سيُلقي نظرة سريعة على معظم الصّور، واحدة تلو الأخرى، بدءا من أيمن وأعلى الصّفحة، قد يتجاهل بعض المنتجات، ولا بأس في ذلك، وقد ينقر على بعض الصّور الّتي تجذب انتباهه أكثر من غيرها. إذا أردت التّصميم بهدف التّصفّح، فاجعل المحتوى مُختصرًا ومرئيًّا، وسهِّل مسح الصّفحة بالعين، لا تحشر عناصر غير مهمّة في الصّفحة، بل ركّز على جوانب المُنتجات الّتي تلبّي مشاعر المستخدم، قدّم وصفًا يناسب هذه الحاجات، فلو كان يحبّ الأسماء التّجاريّة، فاعرض شعارات الشّركات بجوار المنتجات، وهلمّ جرًا. البحث عندما يحاول المُستخدم إيجاد شيء ما في ذهنه، فقد يبدو الأمر مُشابهًا للتصفّح، إلّا أنّ دراسات تتبّع العين تبيّن سلوكًا مختلفًا تمامًا. فالمستخدم الباحث سيتجاهل منتجات وصور كثيرةً، وسيُعينه تنظيم موقعك بصورة حسنة على تتبّع الخيارات بصورة منهجيّة، فهو لا يُريد أن يفوته أحدها. واجهة مثل واجهة موقع Pinterest غير مناسبة لهؤلاء المستخدمين لأنّها تبدو فوضويّة، ولكنّ إمكانيّة تصفيّة الخيارات قد تكون مفيدة. إذا أردت التّصميم بهدف البحث، فركّز على مزايا كلّ عنصر، فلو كان يبحث عن مُنتجٍ بصفات مُعيّنة فسيقف عند كل صورة فيها هذه الصّفات، أمّا غيرها فسيكون عقبة أمامه. أبرز المزايا الّتي تكون أساسيّة لمعظم المستخدمين، ولا شيء غيرها. تجاهل كون الموقع مليئًا بالمعلومات، فلا بأس في ذلك طالما كانت المعلومات مُفيدة. عندما يجد المُستخدم ما يُريد، فسينقر على المُنتج لقراءة معلومات أكثر أو لشرائه، وسيتوقّع معلومات مُفيدة مثل اسم المنتج وصوره وآراء المُستخدمين. الاكتشاف لنتفرض مثلًا أن لديك منتجًا رائعًا لم يجده مستخدمو موقعك، وتعتقد أنّهم قد يشترونه إن عُرض لهم، فكيف تخلق قابليّة الاكتشاف؟ قد تكون فكرتك عن الاكتشاف مخالفة تمامًا للواقع، فمرحبًا بك إلى عالم تجربة المُستخدم الغريب! فيما يلي فكرتان خاطئتان عن الاكتشاف: ستضيف المُنتج إلى القائمة الرّئيسيّة، أو تُنشئ إعلانات في أعلى الصّفحة تدعو لشرائه. تتوقّع أن مُستخدميك الأكثر وفاءًا سيجدون المنتج أوّلًا، لأنّه يقضون وقتًا أطول مع تصميمك. كلا الفكرتين خاطئتان. أوّلًا: لا ينقر المستخدمون على ما في القائمة إلا إن كانوا يبحثون عن شيء معيّن. لا أحد "يكتشف" من خلال القائمة. كما أن الإعلانات في أعلى الصّفحة غير مُجدية لأنّها لم تكن يومًا مُجدية! ألم تستخدم الإنترنت من قبل؟ ما الّذي سيجعل مستخدميك يُقبلون على هذا الإعلان على حين غرّة؟! ثانيًا: كلّما خَبِر مُستخدموك تصميمك، قلّت إمكانيّة اكتشافهم لأشياء جديدة، فالواقع أنّه ما من أحد سوى المُبتدئين يتصفّحون المواقع والتّطبيقات بحثًا عمّا يمكن إنجازه بها، وأمّا الخبراء فيعرفون ما يريدون، وكيف يُتِمّونه، فلم يتصفّحون؟ "إن أعجبك هذا، فقد يعجبك هذا أيضا..." بدلًا من ذلك، دع مستخدميك يجدون ما يبحثون عنه بالفعل، ثمّ اعرض عليهم أشياء جديدة مرتبطة بها بحيث يمكنهم "اكتشافها"، قد تعتقد أنّ هذا إخفاء لها، إلّا أنّه في الحقيقة أفضل ما يمكن فعله لضمان اكتشافها. في مواقع مثل Reddit، يأتي المستخدمون بحثًا عن أعلى المواضيع تقييمًا، وليس أحدثها، ولكن إن لم يُصوّت أحد على المواضيع الجديدة، لن يكون هناك مواضيع جديدة أعلى تقييمًا! ولهذا يضيف Reddit بعض المواضيع الجديدة من الفئات الّتي يحبّها الزّائر بين الأعلى تقييمًا، بحيث تحصل على تقييمات جديدة، لتعود الدّورة من جديد. كلّما فهمت مستخدميك، زاد فهمك لهدف تصميمك، ومن هنا تنبع أهميّة أبحاث المستخدمين. ترجمة بتصرّف للدّرس Browsing vs. Searching vs. Discovery من سلسلة Daily UX Crash Course لصاحبها Joel Marsh. اقرأ أيضًا النسخة العربية الكاملة من كتاب مدخل إلى تجربة المستخدم (User Experience - UX) 1.0.0 كيف تتصرف في جلسة بحث عن تجربة المستخدم UX أساسيات البحث في تصميم تجربة المستخدم هل تحتاج إلى المساعدة في اختيار أداة واجهة وتجربة المستخدم UX/UI؟ أنت في المكان الصحيح بيان تجربة المستخدم: مبادئ التصميم، دراسة المستخدم، التصميم المرتكز حول المستخدم، تصميم وتخطيط تجربة المستخدم

عند تشغيل خدمات وتطبيقات متعددة على عنقود Kubernetes، يمكن أن يساعدك مكدس سجلات مركزي على مستوى العنقود على فرز الحجم الكبير لبيانات السجلات التي تنتجها كائنات Pod، وتحليل تلك السجلّات بسرعة. أحد حلول التسجيل المركزية الشائعة هو مكدس EFK الذي يضم التطبيقات الثلاث Elasticsearch، وFluentd وKibana. Elasticsearch هو محرك بحث فوري ومُوزّع وقابل للتحجيم يسمح بالبحث في النصوص والبيانات المنظَّمة وكذلك التحليلات. يُستخدم Elasticsearch عادةً لفهرسة كميات كبيرة من بيانات السجلّات والبحث فيها، ولكن يمكن استخدامه أيضًا للبحث في العديد من أنواع المستندات المختلفة. يُنشَر Elasticsearch عادة جنبًا إلى جنب مع Kibana، وهي واجهة أمامية ولوحة تحكم فعّالة لعرض البيانات. تتيح Kibana استكشاف بيانات سجل Elasticsearch الخاص بك من خلال واجهة ويب، وإنشاء لوحات تحكم واستعلامات للإجابة بسرعة على الأسئلة والحصول على نظرة مفصَّلة عن تطبيقات Kubernetes. سنستخدم في هذا الدرس Fluentd لجمع بيانات السجل وتحويلها وشحنها إلى سند Elasticsearch الخلفي. Fluentd هو مُجمِّع بيانات شائع الاستخدام، ومفتوح المصدر، سنعدّه على عُقد Kubernetes لتتبّع ملفات سجلّات الحاوية، وتصفية وتحويل بيانات السجل، وتسليمها إلى عنقود Elasticsearch، حيث تُفهرَس وتُخزَّن. سنبدأ بإعداد وتشغيل عنقود Elasticearch قابل للتحجيم، ثم ننشئ خدمة Kibana وعمليّة النشر الخاصّة بها على Kubernetes. في الختام، سنعدّ Fluentd بصيغة متحكّم DaemonSet حتى يُشغَّل على كل عقدة عاملة على Kubernetes. المتطلبات الأساسية قبل أن تبدأ بهذا الدليل، تأكد من توفر ما يلي لك: عنقود Kubernetes، الإصدار 1.10 فما فوق، مع تفعيل التحكّم في الوصول اعتمادًا على الدور (Role-Based Accedd Control, RBAC). تأكّد أن العنقود لديه موارد كافية لتشغيل مكدس EFK، وإن لم يكن، زد حجم العنقود بإضافة عقَد عاملة جديدة. سننشر Elasticsearch على ثلاث كائنات Pod (يمكنك تقليل العدد إلى 1 إنْ لزم الأمر)، بالإضافة إلى كائن Pod واحد لبيئة Kibana. ستشغّل كل عقدة عاملة كائن Pod لتطبيق Fluentd. يتكون العنقود في هذا الدليل من ثلاث عقد عاملة ومستوى تحكم مُدبَّر (Managed control plane) واحد. أداة سطر الأوامر kubectl مُثبّتة على جهازك المحلي، مُعدَّة للاتصال بالعنقود. يمكنك قراءة المزيد حول تثبيت kubectl في التوثيق الرسمي. بمجرد الانتهاء من إعداد هذه المكونات، تكون جاهزًا للبدء بهذا الدليل. الخطوة الأولى: إنشاء فضاء أسماء (Namespace) قبل إطلاق عنقود Elasticsearch، سنُنشئ أولاً فضاء أسماء نثبّت فيه جميع أدوات التسجيل الخاصة بنا. يتيح لك Kubernetes فصل الكائنات التي تعمل في العنقود باستخدام تجريد ينشئ "عنقودَا افتراضيًّا" يُسمّى فضاء الأسماء. سننشئ في هذا الدليل فضاء أسماء نطلق عليه kube-logging نثبّت فيه مكونات مكدس EFK. علاوةً على ذلك، سيسمح لنا فضاء الأسماء هذا بتنظيف مكدس EFK وإزالته بسرعة دون فقدان وظائف أخرى في عنقود Kubernetes. للبدء، تَحقَّق أولاً من فضاءات الأسماء الموجودة في العنقود باستخدام kubectl: $ kubectl get namespaces يجب أن ترى فضاءات الأسماء الثلاثة المبدئية التالية، والتي تأتي مُثبَّتة مسبقًا مع عنقود Kubernetes: NAME STATUS AGE default Active 5m kube-system Active 5m kube-public Active 5m يحتوي فضاء الأسماء default على كائنات أنشئت بدون تحديد فضاء أسماء لها. يحتوي فضاء الأسماء kube-system على كائنات أنشأها واستخدمها نظام Kubernetes، مثلkube-dns، kube-proxy، وkubernetes-dashboard. من الجيد الحفاظ على نظافة فضاءات الأسماء هذه وعدم تلويثها بأحمال عمل التطبيقات والأدوات الأخرى. فضاء الأسماء kube-public هو الآخرأنشئ تلقائيًا ويمكن استخدامه لتخزين الكائنات التي تريد لها أن تكون قابلة للقراءة ويمكن الوصول إليها عبر العنقود بأكمله، حتى للمستخدمين الذين لم تستوثق منهم (Unauthenticated users). لإنشاء فضاء الأسماء kube-logging، أولًا افتح ملفًّا يُسمى kube-logging.yaml باستخدام المحرر المفضل لديك، مثل nano: $ nano kube-logging.yaml داخل المحرر، الصق كائن فضاء الأسماء التالي المكتوب بصيغة YAML: kind: Namespace apiVersion: v1 metadata: name: kube-logging ثم احفظ الملف وأغلقه. هنا، نحدد نوع كائن Kubernetes بأنه فضاء أسماء. لمعرفة المزيد حول كائنات فضاء الأسماء، راجع إرشادات فاضاءات الأسماء في توثيق Kubernetes. نحدد أيضًا إصدار واجهة تطبيقات Kubernetes المستخدم لإنشاء الكائن (v1)، ونعيّن قيمة الحقل name (الاسم) لتكون kube-logging. أنشئ فضاء أسماء باستخدام الأمر kubectl create مع خيار اسم الملف f-، مباشرة بعد تحرير ملف كائن فضاء الأسماء kube-logging.yaml، وذلك على النحو التالي: $kubectl create -f kube-logging.yaml تظهر المُخرجات كالتالي: namespace/kube-logging created يمكنك بعد ذلك التأكد من إنشاء فضاء الأسماء بنجاح: $ kubectl get namespaces عند هذه النقطة، من المُفترض أن ترى فضاء الأسماء الجديد kube-logging : NAME STATUS AGE default Active 23m kube-logging Active 1m kube-public Active 23m kube-system Active 23m يمكننا الآن نشر عنقود Elasticsearch في فضاء الأسماء المعزول الخاص بالتسجيل. الخطوة 2 - إنشاء Elasticsearch StatefulSet الآن بعد أن أنشأنا فضاء أسماء لاستيعاب مكدس السجلّات، يمكننا البدء في طرح مكوناته المختلفة. سنبدأ أولاً بنشر عنقود Elasticsearch من ثلاث عُقد. في هذا الدليل نستخدم ثلاث كائنات Pod ليعمل عليها عنقود Elasticsearch، والهدف هو تجنب مشكلة "الدماغ المنصدع" (Split-brain)، التي قد تحدث في العنقود متعدّد العقد. تحدث مشكلة "الدماغ المنصدع" عندما يتعذر على عُقدة (أو عدة عقد) التواصل مع العقد الأخرى، فتُختار عدة عقد لتلعب دور القبطان (Master). مع ثلاث عقد، إذا انفصلت عقدة عن العنقود يمكن للعقدتين الأخريين انتخاب قبطان جديد ويمكن للعنقود أن يستمر في العمل بينما تحاول العقدة الضائعة الالتحاق. راجع المقالين A new era for cluster coordination in Elasticsearch وVoting configurations لمعرفة المزيد عن المشكلة المذكورة. إنشاء خدمة مجهولة العنوان (Headless Service) للبدء، سننشئ خدمة Kubernetes مجهولة العنوان تسمى elasticsearch تعرّف اسم نطاق لكائنات Pod الثلاثة الموجودة في عنقود Elasticsearch. لا توازن الخدمة مجهولة العنوان الحمل وليس لديها عنوان IP ثابت. راجع توثيق Kubernetes للمزيد عن هذه الخدمات. افتح الملف elasticsearch_svc.yaml بمحرّر النصوص المفضل لديك: $ nano elasticsearch_svc.yaml الصق فيه خدمة Kubernetes التالية (بصيغة YAML): elasticsearch_svc.yaml kind: Service apiVersion: v1 metadata: name: elasticsearch namespace: kube-logging labels: app: elasticsearch spec: selector: app: elasticsearch clusterIP: None ports: - port: 9200 name: rest - port: 9300 name: inter-node ثم احفظ الملف وأغلقه. نعيّن خدمة (service) تسمى elasticearch في فضاء الأسماء kube-logging ، ونعطيها اللصيقة app: elasticsearch. ثم نعيّن القيمة app: elasticsearch للحقل spec.selector. لكي تختار لخدمة كائن Pod عن طريق اللصيقة app: elasticsearch. عندما نربط متحكّم StatefulSet في عنقود Elasticsearch الخاص بنا مع هذه الخدمة، سترجع الخدمة سجل DNS من النوع A يشير إلى كائنات Pod ذات اللصيقة app: elasticsearch في عنقود Elasticsearch. ثم نعيّن الحقل clusterIP لتكون قيمته None، ممّا يجعل الخدمة مجهولة العنوان. أخيرًا، نُحدد المنافذ 9200 و9300 التي تُستخدَم على التوالي للتفاعل مع واجهة التطبيقات من النوع، وللتواصل الداخلي بين العقد. أنشئ الخدمة باستخدام kubectl: $ kubectl create -f elasticsearch_svc.yaml يجدر أن تظهر مُخرجات كالتالي: service/elasticsearch created أخيرًا، تحقق جيدًا من إنشاء الخدمة بنجاح باستخدام kubectl get: kubectl get services --namespace=kube-logging يجب أن ترى ما يلي: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE elasticsearch ClusterIP None <none> 9200/TCP,9300/TCP 26s الآن بعد أن أعددنا خدمتنا المستقرة مجهولة العنوان والنطاق elasticsearch.kube-logging.svc.cluster.local. لكائنات Pod الخاصة بنا، يمكننا المضي قدمًا وإنشاء متحكّم المجموعة ذات الحالة (StatefulSet). إنشاء مجموعة ذات حالة (StatefulSet) من كائنات Pod يسمح لك كائن StatefulSet في Kubernetes بتعيين هوية ثابتة لكائنات Pod ومنحها تخزينًا مستقرًّا ودائما. يحتاج Elasticsearch لتخزين مستقر لضمان ديمومة البيانات عند إعادة جدولة كائنات Pod وإعادة تشغيلها. راجع التوثيق الرسمي للمزيد حول كائنات StatefulSet. افتح الملف المُسمّى elasticsearch_statefulset.yaml في المُحرر المفضل لديك: $ nano elasticsearch_statefulset.yaml سنمرّ خطوة خطوة على تعريف كائن StatefulSet من خلال لصق أجزاء من التعريف في الملف المذكور. نبدأ بنسخ ثم لصق الجزء التالي: apiVersion: apps/v1 kind: StatefulSet metadata: name: es-cluster namespace: kube-logging spec: serviceName: elasticsearch replicas: 3 selector: matchLabels: app: elasticsearch template: metadata: labels: app: elasticsearch نعرّف في الجزء أعلاه كائن StatefulSet باسم es-cluster في فضاء الأسماء kube-logging. ثم نربطه بخدمة elasticsearch التي أنشئت مسبقًا باستخدام حقل serviceName، ممّا يضمن إمكانية الوصول إلى كل كائن Pod في المجموعة باستخدام النطاق التالي: es-cluster-[0,1,2].elasticsearch.kube-logging.svc.cluster.local، حيث [0,1,2] يُشير إلى العدد الترتيبي لكائن Pod. نحدد ثلاث نسخ متطابقة (كائنات Pod) بتعيين القيمة 3 للحقل replicas، ونعيّن القيمة app: elasticseach للمُحدِّد matchLabels، ونكرّر الأمر مع الحقل spec.template.metadata.. يجب أن تتطابق قيمتا الحقلين .spec.selector.matchLabels و .spec.template.metadata.labels. يمكننا الآن الانتقال إلى مواصفات الكائن. ألصق الجزء التعريفي التالي، المكتوب بصيغة YAML، أسفل الجزء السابق: . . . spec: containers: - name: elasticsearch image: docker.elastic.co/elasticsearch/elasticsearch:7.2.0 resources: limits: cpu: 1000m requests: cpu: 100m ports: - containerPort: 9200 name: rest protocol: TCP - containerPort: 9300 name: inter-node protocol: TCP volumeMounts: - name: data mountPath: /usr/share/elasticsearch/data env: - name: cluster.name value: k8s-logs - name: node.name valueFrom: fieldRef: fieldPath: metadata.name - name: discovery.seed_hosts value: "es-cluster-0.elasticsearch,es-cluster-1.elasticsearch,es-cluster-2.elasticsearch" - name: cluster.initial_master_nodes value: "es-cluster-0,es-cluster-1,es-cluster-2" - name: ES_JAVA_OPTS value: "-Xms512m -Xmx512m" هنا نحدد كائنات Pod في المجموعة ذات الحالة (StatefulSet). نسمّي الحاويات elasticsearch ونختار صورة Docker من الرابط docker.elastic.co/elasticsearch/elasticsearch:7.2.0. في هذه المرحلة، يمكنك تعديل وسم الصورة هذا ليتوافق مع صورة Elasticsearch الداخلية الخاصة بك، أو مع إصدار مختلف. لاحظ أنه لأغراض هذا الدليل، اقتصر الااختبارعلى الإصدار 7.2.0 من Elasticsearch. ثم نستخدم الحقل resources لتحديد أن الحاوية تحتاج على الأقل لضمان 10% من وحدة المعالجة المركزية الافتراضية ( 0.1vCPU)، ويمكن أن يزيد الاستخدام ليصل إلى وحدة معالجة كاملة (1vCPU)، أي أننا نعيّن الحد الأقصى لاستهلاك المورد في حالات مثل استقبال كائن Pod لكمية أولية كبيرة من البيانات أو في أوقات الذروة). يجب تعديل هذه القيم اعتمادًا على الحمل المتوقع والموارد المتاحة. راجع توثيق Kubernetes للمزيد عن الطلبات على الموارد وحدوها. ثم نفتح المنفذين 9200 و 9300، مع تسميتهما، بغرض الاتصال بواجهة تطبيقات REST والاتصال الداخلي، على التوالي. نحدد نقطة لتركيب تجزئات التخزين (الحقل volumeMount) ونسمّيها data. وظيفة نقطة التركيب تلك هي تحميل التجزئة المستقرّة (كائن من النوع PersistentVolume) المُسماة data الموجودة ضمن الحاوية على المسار usr/share/elasticsearch/data/. سنحدد مطالب الحجم (VolumeClaims) لهذه المجموعة في جزء لاحق من التعريف. أخيرًا، نعيّن بعض متغيرات البيئة في الحاوية: cluster.name: اسم عنقود Elasticsearch، والذي في هذا الدليل هو k8s-logs. node.name: اسم العقدة، الذي عيّناه للحقل metadata.name. باستخدام valueFrom. ستُترجم هذه القيمة إلى [es-cluster-[0,1,2، اعتمادًا على العدد الترتيبي المعيّن للعقدة. discovery.seed_hosts: يعين هذا الحقل قائمة بالعقد المؤهلة لتؤدّي دور القبطان في العنقود الذي سيؤسس لعملية استكشاف العقد. في هذا الدليل، وبفضل الخدمة مجهولة العنوان التي أعددناها سابقًا، تأخذ كائنات Pod نطاقات بالصيغة es-cluster-[0,1,2].elasticsearch.kube-logging.svc.cluster.local، لذلك عيّنا هذا المتغير وفقًا لذلك. يمكننا تقصير النطاق إلى es-cluster-[0,1,2].elasticsearch باستخدام ترجمة أسماء النطاقات الداخلية في Kubernetes. راجع توثيق Elasticsearch للمزيد عن الاستكشاف في Elasticsearch. cluster.initial_master_nodes: يحدد هذا الحقل أيضًا قائمة عقد مؤهلة لتؤدّي دور القبطان في العنقود ستشارك في عملية انتخاب القبطان. لاحظ أنه في هذا الحقل، يجب تحديد العقد من خلال node.name وليس أسماء المضيفين. ES_JAVA_OPTS: ضبطنا المتغيّر على القيم Xms512m -Xmx512m- لإخبار آلة جافا الافتراضية (JVM) برغبتنا في استخدام 512 ميجابايت لتكون الحد الأدنى والحد الأقصى لحجم كومة الذاكرة المؤقتة. يجب ضبط هذه المعاملات بناءً على توفر الموارد للعنقود واحتياجاته. راجع المقال التالي للمزيد من التفاصيل. يظهر الجزء الموالي من التعريف على النحو التالي: . . . initContainers: - name: fix-permissions image: busybox command: ["sh", "-c", "chown -R 1000:1000 /usr/share/elasticsearch/data"] securityContext: privileged: true volumeMounts: - name: data mountPath: /usr/share/elasticsearch/data - name: increase-vm-max-map image: busybox command: ["sysctl", "-w", "vm.max_map_count=262144"] securityContext: privileged: true - name: increase-fd-ulimit image: busybox command: ["sh", "-c", "ulimit -n 65536"] securityContext: privileged: true في هذه الجزء، نحدد العديد من الحاويات الأولية التي تُشغَّب قبل حاوية تطبيق elasticearch الرئيسية. تُشغَّل هذه الحاويات الأولية (Init Containers) حتى إكمال عملها بالترتيب المحدد. راجع التوثيق الرسمي لمعرفة المزيد عن الحاويات الأولية. تنفّذ الحاوية الأولى، المُسمّاة fix-permissions، أمر chown لتغيير الحساب والمجموعة المالكيْن لمجلّد بيانات دليل Elasticsearch ليصبحا 1000: 1000، وهما معرّفا (UID) مستخدم ومجموعة Elasticsearch. يركّب Kubernetes مجلّد البيانات بالحساب الجذر (root)، مما يجعل وصول Elasticsearch إليه غير ممكن. راجع توثيق Elasticsearch لمزيد من المعلومات حول هذه الخطوة. تنفّذ الحاوية الثانية، المسمّاة increase-fd-ulimit، أمرًا لزيادة حدود استدعاءات mmap التي يمكن لنظام التشغيل إجراؤها، والتي قد يكون عددها افتراضيًا منخفضًا جدًا، مما ينتج عنه أخطاء في الذاكرة. راجع توثيق Elasticsearch لمزيد من المعلومات حول هذه الخطوة. الحاوية الأوليّة التالية هي increase-fd-ulimit والتي تنفّذ الأمر ulimit لزيادة الحد الأقصى لعدد واصفات الملفات المفتوحة (File descriptor). راجع توثيق Elasticsearch لمزيد من المعلومات حول هذه الخطوة. الآن بعد أن حددنا حاوية التطبيق الرئيسية والحاويات الأوليّة التي تُشغَّل قبلها لضبط نظام تشغيل الحاوية، يمكننا إضافة الجزء الأخير إلى ملف تعريف كائن StatefulSet، وهو الجزء المتعلّق بقوالب مطالب الحجم (volumeClaimTemplates). ألصق الجزء التالي المتعلّق بتعريف volumeClaimTemplate: . . . volumeClaimTemplates: - metadata: name: data labels: app: elasticsearch spec: accessModes: [ "ReadWriteOnce" ] storageClassName: do-block-storage resources: requests: storage: 100Gi في هذا الجزء، نحدد المجلد VolumeClaimTemplates الخاص بكائن StatefulSet. سيستخدم Kubernetes هذا المجلّد لإنشاء تجزئات دائمة (PersistentVolumes) لكائنات Pod. في التعريف أعلاه، نسميها data (وهو الاسم الذي نشير إليه في وحدة التخزين التي تم تعريفها سابقًا)، ونعطيها نفس اللصيقة (app: elasticsearch) اللتي أعطيناها لكائن StatefulSet سابقا. ثم نحدد وضع الوصول إلى التجزئات ليكون ReadWriteOnce، مما يعني أنه لا تمكن القراءة والكتابة منها إلّا بواسطة عُقدة واحدة. نحدد الصنف do-block-storage ليكون صنف التخزين إذ أننا نستخدم عنقود Kubernetes من DigitalOcean لأغراض الشرح. يجب تغيير هذه القيمة اعتمادًا على أين تشغّل عنقود Kubernetes الخاص بك. راجع توثيق Kubernetes للمزيد عن التخزين الدائم. أخيرًا، نحدد حجم كل مجلد دائم (PersistentVolume) ليكون 100 غيغابايت. يجب تعديل هذه القيمة حسب احتياجات بيئة الإنتاج الخاصة بك. تبدو المواصفات الكاملة لكائن StatefulSet كالتالي: apiVersion: apps/v1 kind: StatefulSet metadata: name: es-cluster namespace: kube-logging spec: serviceName: elasticsearch replicas: 3 selector: matchLabels: app: elasticsearch template: metadata: labels: app: elasticsearch spec: containers: - name: elasticsearch image: docker.elastic.co/elasticsearch/elasticsearch:7.2.0 resources: limits: cpu: 1000m requests: cpu: 100m ports: - containerPort: 9200 name: rest protocol: TCP - containerPort: 9300 name: inter-node protocol: TCP volumeMounts: - name: data mountPath: /usr/share/elasticsearch/data env: - name: cluster.name value: k8s-logs - name: node.name valueFrom: fieldRef: fieldPath: metadata.name - name: discovery.seed_hosts value: "es-cluster-0.elasticsearch,es-cluster-1.elasticsearch,es-cluster-2.elasticsearch" - name: cluster.initial_master_nodes value: "es-cluster-0,es-cluster-1,es-cluster-2" - name: ES_JAVA_OPTS value: "-Xms512m -Xmx512m" initContainers: - name: fix-permissions image: busybox command: ["sh", "-c", "chown -R 1000:1000 /usr/share/elasticsearch/data"] securityContext: privileged: true volumeMounts: - name: data mountPath: /usr/share/elasticsearch/data - name: increase-vm-max-map image: busybox command: ["sysctl", "-w", "vm.max_map_count=262144"] securityContext: privileged: true - name: increase-fd-ulimit image: busybox command: ["sh", "-c", "ulimit -n 65536"] securityContext: privileged: true volumeClaimTemplates: - metadata: name: data labels: app: elasticsearch spec: accessModes: [ "ReadWriteOnce" ] storageClassName: do-block-storage resources: requests: storage: 100Gi احفظ الملف ثم أغلقه بعد التأكد من محتواه. الآن، انشر ملف StatefulSet باستخدام kubectl: $ kubectl create -f elasticsearch_statefulset.yaml يجب أن تشاهد المُخرجات التالية: statefulset.apps/es-cluster created يمكنك مراقبة حالة StatefulSet أثناء إطلاقه باستخدام kubectl rollout status: $ kubectl rollout status sts/es-cluster --namespace=kube-logging يجب أن ترى المخرجات التالية أثناء إطلاق العنقود: Waiting for 3 pods to be ready... Waiting for 2 pods to be ready... Waiting for 1 pods to be ready... partitioned roll out complete: 3 new pods have been updated... بمجرد نشر كل كائنات Pod، يمكنك التحقق من أن عنقود Elasticsearch الخاص بك يعمل من خلال إرسال طلب إلى واجهة تطبيقات REST. لذا، أعد توجيه المنفذ المحلي 9200 إلى المنفذ 9200 على إحدى عُقد Elasticsearch وهي (es-cluster-0)، باستخدام kubectl port-forward: $ kubectl port-forward es-cluster-0 9200:9200 --namespace=kube-logging ثم، في نافذة طرفية منفصلة، نفذ طلب curl باتجاه واجهة REST: $ curl http://localhost:9200/_cluster/state?pretty يجب أن تظهر المخرجات التالية: { "cluster_name" : "k8s-logs", "compressed_size_in_bytes" : 348, "cluster_uuid" : "QD06dK7CQgids-GQZooNVw", "version" : 3, "state_uuid" : "mjNIWXAzQVuxNNOQ7xR-qg", "master_node" : "IdM5B7cUQWqFgIHXBp0JDg", "blocks" : { }, "nodes" : { "u7DoTpMmSCixOoictzHItA" : { "name" : "es-cluster-1", "ephemeral_id" : "ZlBflnXKRMC4RvEACHIVdg", "transport_address" : "10.244.8.2:9300", "attributes" : { } }, "IdM5B7cUQWqFgIHXBp0JDg" : { "name" : "es-cluster-0", "ephemeral_id" : "JTk1FDdFQuWbSFAtBxdxAQ", "transport_address" : "10.244.44.3:9300", "attributes" : { } }, "R8E7xcSUSbGbgrhAdyAKmQ" : { "name" : "es-cluster-2", "ephemeral_id" : "9wv6ke71Qqy9vk2LgJTqaA", "transport_address" : "10.244.40.4:9300", "attributes" : { } } }, ... تشير المخرجات إلى أنّ العنقود k8s-logs المكوَّن من ثلاث عقد ( es-cluster-1، es-cluster-0 وes-cluster-2.) قد أنشئ بنجاح. العقدة التي تؤدي دور القبطان هي حاليًّا es-cluster-0. الآن بعد أن أصبح عنقود Elasticsearch جاهزًا يمكنك الانتقال إلى إعداد واجهة Kibana الأمامية. الخطوة 3: إنشاء خدمة ونشر كيبانا لإطلاق Kibana على Kubernetes، سننشئ خدمة تسمى kibana، وننشئ أيضًا عملية نشر (Deployment) تتكوّن من كائن Pod واحد. يمكنك تحديد عدد النسخ التي تحتاجها بناءً على احتياجات بيئة الإنتاج الخاصة بك، وتحديد النوع LoadBalancer لتوزيع عبء بين كائنات Pod. هذه المرة ، سننشئ الخدمة والنشر في الملف نفسه. افتح ملفًا يسمى kibana.yaml في محررك المفضل: $ nano kibana.yaml ألصق المواصفات التالية للخدمة: apiVersion: v1 kind: Service metadata: name: kibana namespace: kube-logging labels: app: kibana spec: ports: - port: 5601 selector: app: kibana --- apiVersion: apps/v1 kind: Deployment metadata: name: kibana namespace: kube-logging labels: app: kibana spec: replicas: 1 selector: matchLabels: app: kibana template: metadata: labels: app: kibana spec: containers: - name: kibana image: docker.elastic.co/kibana/kibana:7.2.0 resources: limits: cpu: 1000m requests: cpu: 100m env: - name: ELASTICSEARCH_URL value: http://elasticsearch:9200 ports: - containerPort: 5601 ثم احفظ الملف وأغلقه. في هذه المواصفات، حددنا خدمة تسمى kibana في فضاء الأسماء kube-logging، وأعطيناها اللصيقة app: kibana. حددنا أيضًا أنه يجب الوصول إليها على المنفذ 5601 واستخدمنا اللصيقة app: kibana لتحديد كائنات Pod المُستهدَفة بالخدمة. في مواصفات النشر Deployment، نحدد عملية نشر تُسمى kibana ونحدد أننا نريد كائن Pod واحدا. نستخدم صورة Kibana من الرابط docker.elastic.co/kibana/kibana:7.2.0. عند هذه النقطة يمكنك وضع صورة كيبانا الخاصة أو العامة التي تودّ استخدامها. نحدد أن الحاوية تحتاج على الأقل لضمان 10% من وحدة المعالجة المركزية الافتراضية ( 0.1vCPU)، ويمكن أن يزيد الاستخدام ليصل إلى وحدة معالجة كاملة (1vCPU)، أي أننا نعيّن الحد الأقصى لاستهلاك المورد. يمكنك تغيير هذه المعاملات اعتمادًا على الحمل المتوقع والموارد المتاحة. بعد ذلك ، نستخدم متغير البيئة ELASTICSEARCH_URL لتعيين نقطة النهاية والمنفذ لعنقود Elasticsearch. باستخدام نطاقات Kubernetes نجد أن نقطة النهاية تتوافق مع اسم الخدمة الخاص بها elasticsearch. سيُترجم اسم النطاق إلى قائمة عناوين IP الخاصة بكائنات Pod الثلاث. راجع توثيق Kubernetes للمزيد عن إدارة أسماء النطاقات في Kubernetes. أخيرًا، عيّنا 5601 ليكون منفذ حاويات Kibana، حيث ستعيد خدمة Kibana توجيه الطلبات إليه. يمكنك - بعد التأكّد من إعدادات Kibana - إطلاق الخدمة وتشغيل عملية النشر باستخدام kubectl: $ kubectl create -f kibana.yaml يجب أن تشاهد المخرجات التالية: service/kibana created deployment.apps/kibana created يمكنك التحقق من نجاح إطلاق الخدمة عن طريق تشغيل الأمر التالي: $ kubectl rollout status deployment/kibana --namespace=kube-logging يجب أن تشاهد المخرجات التالية: deployment "kibana" successfully rolled out للوصول إلى واجهة Kibana، سنعيد توجيه منفذ محلي مرة أخرى إلى عُقدة Kubernetes التي تشغّل Kibana. احصل على تفاصيل كائن Pod الخاص بعقدة Kibana باستخدام kubectl get: $ kubectl get pods --namespace=kube-logging المخرجات: NAME READY STATUS RESTARTS AGE es-cluster-0 1/1 Running 0 55m es-cluster-1 1/1 Running 0 54m es-cluster-2 1/1 Running 0 54m kibana-6c9fb4b5b7-plbg2 1/1 Running 0 4m27s هنا نلاحظ أن كائن Pod الخاص بعقدة Kibana يُسمّى kibana-6c9fb4b5b7-plbg2. أعد توجيه المنفذ المحلي 5601 إلى المنفذ 5601 على ذلك الكائن: $ kubectl port-forward kibana-6c9fb4b5b7-plbg2 5601:5601 --namespace=kube-logging يجب أن تظهر المخرجات التالية: Forwarding from 127.0.0.1:5601 -> 5601 Forwarding from [::1]:5601 -> 5601 الآن، زر رابط URL التالي: http://localhost:5601 إذا رأيت صفحة ترحيب Kibana التالية، فقد نجحت في نشر Kibana في عنقود Kubernetes: يمكنك الآن الانتقال إلى إطلاق المكون النهائي لمكدس EFK وهو مُجمِّع السجلات Fluentd. الخطوة 4: إنشاء Fluentd DaemonSet في هذا الدليل، سنعدّ Fluentd بصيغة DaemonSet، وهو نوع من أعباء العمل في Kubernetes يشغّل نسخة من كائن Pod على كل عقدة في عنقود Kubernetes. باستخدام وحدة تحكم DaemonSet هذه، سنطلق وكيل تسجيل Fluentd عبارة عن كائن Pod على كل عقدة من العنقود. راجع هذا المقال من توثيق Kubernetes الرسمي لمعرفة المزيد حول بنية التسجيل هذه. تُلتَقط سجّلات المُخرجات والأخطاء المعيارية (stdout و stderr على التوالي) للتطبيقات العاملة ضمن حاويّات ويُعاد توجيهها إلى ملفات JSON على العقد. سيتتبّع وكيل Fluentd ملفّات السجلّات تلك، ويفرز الأحداث الموجودة فيها، ويحوّل بيانات السجلّات وفي الأخير يشحنها إلى السند الخلفي لحفظ السجلّات على Elasticsearch الذي نشرناه في الخطوة الثانية من هذا الدليل. بالإضافة إلى سجلات الحاوية، يتتبّع وكيل Fluentd سجلات مكونات نظام Kubernetes مثل سجلات kubelet وkube-proxy وDocker. راجع ملف kubernetes.conf المستخدم لإعداد وكيل التسجيل للاطلاع على قائمة كاملة بالمصادر التي يتتبعها وكيل تسجيل Fluentd. راجع توثيق Kubernetes لمعرفة المزيد حول تسجيل الأحداث على مستوى عقد Kubernetes. ابدأ بفتح الملف fluentd.yaml في محرر النصوص المفضل لديك: $ nano fluentd.yaml مرة أخرى ، سنلصق تعريفات الكائن جزءًا جزءًا، مع شرح سياق التعريفات في كل جزء. نستند في هذا الدليل على مواصفات متحكّم Fluentd DaemonSet التي يوفرها فريق صيانة Fluentd. مورد مفيد آخر يقدمه مشرفو Fluentd هو مقالات Flunetd ضمن توثيق Kuberentes. أولاً، الصق في تعريف ServiceAccount التالي: apiVersion: v1 kind: ServiceAccount metadata: name: fluentd namespace: kube-logging labels: app: fluentd هنا، قمنا بإنشاء حساب خدمة باسم flentd ستستخدمه كائنات Pod التابعة لخدمة Fluentd في الوصول إلى واجهة تطبيقات Kubernetes. ننشئ الحساب في فضاء الأسماء kube-logging ونعطيه مرة أخرى اللصيقة app: fluentd. راجع توثيق Kubernetes للمزيد عن حسابات الخدمة في Kubernetes. بعد ذلك، الصق الجزء التالي الذي يعرّف الكائن ClusterRole : . . . --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: fluentd labels: app: fluentd rules: - apiGroups: - "" resources: - pods - namespaces verbs: - get - list - watch هنا نحدد ClusterRole يسمى fluentd نمنحه صلاحيات get،وlist و watch على كائنات Pod وفضاءات الأسماء. تسمح الكائنات من النوع ClusterRoles بمنح الوصول إلى موارد Kubernetes في نطاق العنقود مثل العقَد. راجع [فصل استخدام تراخيص RBAC]() ضمن توثيق Kubernetes، للمزيد عن التحكم في الوصول المعتمد على الأدوار (RBAC). الآن، الصق الجزء التعريفي التالي المتعلق بكائن ClusterRoleBinding: . . . --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: fluentd roleRef: kind: ClusterRole name: fluentd apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: fluentd namespace: kube-logging نعرّف كائنًا من النوع ClusterRoleBinding ونسمّيهfluentd. وظيفة هذا الكائن هي الربط بين الكائن من النوع ClusterRole وحساب خدمة fluentd، ممّا يمنح الخدمة الصلاحيّات المدرجة في الكائن من النوع ClusterRole الذي أسميناهfluentd . عند هذه النقطة يمكننا البدء بلصق التعريفات ضمن المواصفات الفعليّة لمتحكّم DaemonSet: . . . --- apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd namespace: kube-logging labels: app: fluentd هنا، نحدد متحكّم DaemonSet يُسمى fluentd في فضاء أسماء kube-logging ونعطيها اللصيقة app: fluentd. بعد ذلك، الصق الجزء التعريفي التالي: . . . spec: selector: matchLabels: app: fluentd template: metadata: labels: app: fluentd spec: serviceAccount: fluentd serviceAccountName: fluentd tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule containers: - name: fluentd image: fluent/fluentd-kubernetes-daemonset:v1.4.2-debian-elasticsearch-1.1 env: - name: FLUENT_ELASTICSEARCH_HOST value: "elasticsearch.kube-logging.svc.cluster.local" - name: FLUENT_ELASTICSEARCH_PORT value: "9200" - name: FLUENT_ELASTICSEARCH_SCHEME value: "http" - name: FLUENTD_SYSTEMD_CONF value: disable هنا، نطابق اللصيقة app: fluentd المُعرَّفة في metadata.labels.، ثم نعيّن متحكّم DaemonSet لحساب خدمة fluentd. نختار أيضًا كائنات Pod التي تطابق المحدّد app: fluentd ليتولّى المتحكّم DaemonSet إدارتها. بعد ذلك، نحدد تسهيلاً بلا جدول زمني (NoSchedule toleration) لمطابقة الشائبة (Taint) المكافئة على عقد Kubernetes الرئيسية (القبطان). نضمن بذلك أنّ المتحكّم DaemonSet سيُطلَق أيضًا على العقد الرئيسيى في على سادة Kubernetes. أزل هذا التسهيل إذا كنت لا ترغب في تشغيل كائن Pod لتطبيق Fluentd على العقد الرئيسية الخاصة بك. راجع هذا الفصل في توثيق Kubernetes للمزيد عن التسهيلات والشوائب. بعد ذلك، نبدأ في تحديد حاوية كائن Pod، والتي نسميها fluentd. يستخدم هذا الدليل صورة رسمية من توزيعة دبيان يوفّرها فريق صيانة Fluentd. عدّل وسم image في مواصفات الحاوية إذا كنت ترغب في استخدام صورة Fluentd خاصة أو عامة، أو استخدام صورة بإصدار مختلف. يتوفر ملف Dockerfile ومحتويات هذه الصورة في مستودع fluentd-kubernetes-daemonset على Github. بعد ذلك، نضبط Fluentd باستخدام بعض متغيرات البيئة: FLUENT_ELASTICSEARCH_HOST: نعيّن قيمة هذا المتغيّر لتكون اسم نطاق خدمة Elasticsearch مجهولة العنوان المُحدَّد سابقًا elasticsearch.kube-logging.svc.cluster.local. يُترجم اسم النطاق هذا إلى قائمة عناوين IP لكائنات Pod الثلاث الخاصة بتطبيق Elasticsearch. من المُرجَّح أن يكون عنوان مضيف Elasticsearch الحالي هو عنوان IP الأول في القائمة المُرجَعة. لتوزيع السجلات على العنقود، ستحتاج إلى تعديل إعدادات مُلحَق Fluentd الخاص بمُخرجات Elasticsearch. راجع توثيق Fluentd للمزيد حول هذا الملحق. FLUENT_ELASTICSEARCH_PORT: نحدّد قيمة المتغيّر لتكون المنفذ الذي عيّناه سابقًا، 9200. FLUENT_ELASTICSEARCH_SCHEME: نعيّن القيمة http. FLUENTD_SYSTEMD_CONF: نعيّن القيمة disable لحذف مُخرجات systemd غير المضبوطة في الحاوية. أخيرًا، نلصق الجزء التالي من التعريف: . . . resources: limits: memory: 512Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers هنا نحدد القيمة 512 ميجابايت لتكون الحد الأقصى للذاكرة على كائن Pod الخاص بتطبيق Fluentd الذي نضمن له 0.1 من المعالج الافتراضي (0.1vCPU) و 200 ميجابايت من الذاكرة. يمكنك تدقيق حدود الموارد والطلبات بناءً على حجم السجلّات المتوقعة والموارد المتاحة. بعد ذلك، نقوم نركّب مسارات المضيف var/log/ و var/lib/docker/containers/ في الحاوية باستخدام نقطتيْ التركيب (volumeMounts) المذكورتيْن varlog و varlibdockercontainers . تُعرَّف التجزئات (volumes) في نهاية الجزء السابق. الوسيط الأخير الذي نعرّفه هو terminationGracePeriodSeconds، والذي يمنح 30 ثانية لإيقاف Fluentd بأمان عند استقبال إشارة SIGTERM. بعد 30 ثانية، تُرسَل إلى الحاويات إشارة SIGKILL. القيمة الافتراضية للوسيط terminationGracePeriodSeconds هي 30 ثانية، لذلك في معظم الحالات يمكن إغفال هذا الوسيط. راجع هذا المقال من غوغل عن أفضل الممارسات لإيقاف أعباء العمل على Kubernetes. يجب أن تبدو المواصفات الكاملة لتطبيق Fluentd كما يلي: apiVersion: v1 kind: ServiceAccount metadata: name: fluentd namespace: kube-logging labels: app: fluentd --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: fluentd labels: app: fluentd rules: - apiGroups: - "" resources: - pods - namespaces verbs: - get - list - watch --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: fluentd roleRef: kind: ClusterRole name: fluentd apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: fluentd namespace: kube-logging --- apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd namespace: kube-logging labels: app: fluentd spec: selector: matchLabels: app: fluentd template: metadata: labels: app: fluentd spec: serviceAccount: fluentd serviceAccountName: fluentd tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule containers: - name: fluentd image: fluent/fluentd-kubernetes-daemonset:v1.4.2-debian-elasticsearch-1.1 env: - name: FLUENT_ELASTICSEARCH_HOST value: "elasticsearch.kube-logging.svc.cluster.local" - name: FLUENT_ELASTICSEARCH_PORT value: "9200" - name: FLUENT_ELASTICSEARCH_SCHEME value: "http" - name: FLUENTD_SYSTEMD_CONF value: disable resources: limits: memory: 512Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers احفظ الملف وأغلقه بعد ضبط إعداد المتحكّم DaemonSet لتطبيق Fluentd. الآن، أطلق DaemonSet باستخدام kubectl: $ kubectl create -f fluentd.yaml يجب أن تشاهد الناتج التالي: serviceaccount/fluentd created clusterrole.rbac.authorization.k8s.io/fluentd created clusterrolebinding.rbac.authorization.k8s.io/fluentd created daemonset.extensions/fluentd created تحقق من نجاح إطلاق DaemonSet باستخدام kubectl: $ kubectl get ds --namespace=kube-logging يجب أن ترى الحالة الظاهرة في المُخرجات التالية: NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE fluentd 3 3 3 3 3 <none> 58s تشير النتيجة أعلاه إلى وجود ثلاث كائنات Pod قيد التشغيل ويعمل عليها المتحكّم fluentd. يتوافق هذا العدد مع عقد Kubernetes. يمكننا الآن النظر في Kibana للتحقق من أن بيانات السجلّات تُجمَع وتُشحَن كما نريد إلى Elasticsearch. استخدم المتصفّح لفتح العنوان التالي http://localhost:5601، مع استمرار تنفيذ الأمرkubectl port-forward. اضغط على زر Discover (اكتشف) في قائمة التنقل اليسرى: يجب أن تظهر نافذة الإعدادات التالية: تتيح لك هذه النافذة تحديد مؤشرات Elasticsearch التي ترغب في استكشافها في Kibana. لمعرفة المزيد، راجع المقال التالي في توثيق Kibana للمزيد عن أنماط الفهرسة في Kibana. في الوقت الحالي، سنستخدم نمط محارف البدل logstash-* لالتقاط جميع بيانات السجلّات في عنقود Elasticsearch الخاص بنا. اكتبlogstash-* في مربع النص ثم انقر على Next (التالي). ستنتقل بعد ذلك إلى الصفحة التالية. تسمح هذه النفاذة بإعداد الحقل الذي سيستخدمه Kibana لتصفية بيانات السجل حسب الوقت. في القائمة المنسدلة، حدد حقلtimestamp@، واضغط على Create index pattern (إنشاء نمط فهرس). الآن، اضغط على Discover (اكتشف) في قائمة التنقل اليسرى. يجب أن تشاهد مخطّطًا بيانيّا وبعض المُدخلات الأخيرة في السجلّات. بالوصول إلى هذه النقطة تكون قد نجحت في إعداد حزمة EFK وإطلاقها على عنقود Kubernetes. راجع دليل مستخدم Kibana لمعرفة كيفية استخدام Kibana لتحليل بيانات السجل. في القسم الاختياري التالي، سننشر كائن Pod لعدّاد بسيط يطبع أعدادًا على وحدة الإخراج المعيارية (stdout)، ونعثر على سجلاته في Kibana. الخطوة 5 (اختياري) - اختبار تسجيل الحاويات لتوضيح حالة بسيطة لاستخدام Kibana لاستكشاف أحدث السجلات على كائن Pod معيّن، سننشر كائن Pod محدود الإمكانيّات يطبع أعدادًا متسلسلة على وحدة stdout. لنبدأ بإنشاء كائن Pod. افتح ملفًا يسمى counter.yaml في محررك المفضل: $ nano counter.yaml ثم الصق مواصفات التالية لكائن Pod: apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: [/bin/sh, -c, 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done'] احفظ الملف ثم أغلقه. تعرّف المواصفات كائن Pod محدود يُسمى counter ينفّذ حلقة while تكرارية تطبع أعدادًا تسلسلية. ننشر counter باستخدامkubectl: $ kubectl create -f counter.yaml بمجرد إنشاء كائن Pod وتشغيله، انتقل مرة أخرى إلى لوحة معلومات Kibana. أدخل العبارة kubernetes.pod_name: counter في شريط البحث ضمن صفحة Discover (اكتشف). تصفّي العبارة السابقة بيانات السجلّات لعرض البيانات القادمة من كائن Pod المسمَّىcounter دون غيره. يمكنك النقر على أي من مُدخلات السجل لعرض بيانات وصفية إضافية مثل اسم الحاوية، وعقدة Kubernetes، وفضاء الأسماء، والمزيد. خاتمة أوضحنا في هذا الدليل كيفية إعداد وتهيئة Elasticsearch و Fluentd و Kibana على عنقود Kubernetes. استخدمنا الحد الأدنى لإنشاء بنية تسجيل تتكون من وكيل تسجيل واحد يعمل على كل عقدة Kubernetes عاملة. قبل نشر مكدس التسجيل هذا على عنقود Kubernetes ضمن بيئة إنتاج، من الأفضل ضبط متطلبات الموارد وحدودها كما هو موضح في هذا الدليل. قد تحتاج أيضًا إلى إعدادX-Pacl لتمكين ميزات المراقبة والأمان المضمنة. تتكون بنية التسجيل التي استخدمناها هنا من ثلاث كائنات Pod لتطبيق Elasticsearch، وكائن Pod واحد لتطبيق Kibana (بدون موازنة الحِمل)، ومجموعة من كائنات Pod لتطبيق Fluentd تُشغَّل على أنها متحكّمات DaemonSet. قد ترغب في تحجيم هذا الإعداد وفقًا لحالة استخدام بيئة الإنتاج الخاصة بك. راجع هذا المقال للمزيد عن حجيم Elasticsearch و Kibana. يسمح Kubernetes أيضًا ببُنى أكثر تغقيدًا لوكلاء التسجيل ممّا قد يتناسب أكثر مع استخداماتك. راجع هذا المقال على توثيق Kubernetes للمزيد عن بنية السجلّات في Kubernetes. ترجمة - وبتصرّف - للمقال How To Set Up an Elasticsearch, Fluentd and Kibana (EFK) Logging Stack on Kubernetes لصاحبه Hanif Jetha.

يترك غوغل لك أدلةً تساعدك في أنْ تصبح مسوّقاً أفضل - وربّما لا تكون قد رأيتها. وظيفة كلّ مسوّقٍ اليوم، سواء أكان يعمل بطريقة الدفع عن كلّ نقرةٍ "PPC"، أو تحسين الظهور في محرّكات البحث"SEO"، أو مكاتب الحجز المركزية "CRO"، أو بالمحتوى، هي أنْ يعمل على حلّ مشاكل الناس. تحيطك غوغل علمًا بالشركات التي تقوم بذلك بشكلٍ جيّدٍ، والشركات التي تخيّب أمل الناس. تحسين الظهور في محركات البحث "SEO" متغيرٌ باستمرار، بمساعدة الذكاء الاصطناعيّ، وتعلّم الآلة، والبيانات المجموعة على مدى السنين، يتحسّن أداء محركات البحث في التنبؤ بما يريده الناس. في مؤتمر الحث على اتخاذ الإجراءات "Call to Action Conference" الأخير، أوضح مؤسّس "سير إنتيراكتيف" "ويل رينولدز" أنّه مع ازدياد اهتمام محّركات البحث بحلّ مشكلات الناس، ستغدو مجموعة أدوات تحسين الظهور محرّكات البحث "SEO" القديمة أدواتٍ من الماضي : وبعبارةٍ أخرى، فإنّ سباق البحث لم يعد مقتصرًا على الكلمات الرئيسيّة —بل على كون علامتك التجاريّة موثوقةً وملتزمةً بحلّ مشكلات الناس. البحث عن أدلّة لحلّ مشكلات الاحتمالات والخبر السارّ هو أنّه هناك بعض الأماكن التي يمكن أنْ تبدأ البحث فيها لمعرفة ما يريده عملاؤك، حتّى تتمكّن من استخراجها. ويقترح "ويل" مكانين يمكن لكافّة المسوّقين البحث فيهما لإيجاد حلولٍ أفضل لمشاكل زبائنهم، مما يساعدهم في الحصول نتائج أفضل. 1: مقارنة طلبات البحث عندما يكون عملاؤك المستقبليّون في مرحلة التقييم من مسيرتهم، فمن المحتمل أنْ يقارنوك مع منافسيك. يقوم عملاؤك بكتابة أشياء كهذه: "الأفضل" و "مقارنة" و "تعليقات". تشير هذه الكلمات الرئيسيّة إلى أنّهم ليسوا بالضرورة مقتنعين بك بعد — فَهُم يبحثون عن مقارنة. بمعرفتك لذلك، كيف يمكنك اكتشاف ما يريدونه بالضبط حتى تتمكّن من تقديمه لهم؟ افحص النتائج الرئيسية وبالنظر إلى أعلى النتائج الرئيسيّة ستتوصّل إلى رؤيةٍ أفضل عمّا يريد الناس رؤيته فعلاً. في هذا المثال قدّم "ويل" لنا طلب بحث عن "أفضل البرامج لإدارة علاقات العملاء"، فإنّ جميع النتائج الأعلى أجراً هي عبارة عن شركات، في حين أنّ أهمّ النتائج الرئيسية هي عبارةٌ عن مقارنات: النتائج من 1 إلى 4 هي عبارة عن إعلانات. أمّا النتيجتان اللتان في الأسفل فَهُما نتيجتان رئيسيّتان. مصدر الصورة Wil’s CTAConf talk إنّ التناقض بين نوع المحتوى الرئيسيّ الذي يتمّ عرضه ونوع المحتوى في الإعلانات يخبرنا بأنّ المحتوى المدفوع لا يحلّ المشكلة التي يبحث عنها الأشخاص بشكلٍ مباشر. وهذا يعطي تلميحًا للمسوّقين الأذكياء بأنّه عندما يستخدم الناس عبارات للبحث مثل "أفضل"، فهُم ليسوا جاهزين للاستقرار على أحدهم بعد. بل أنّهم يبحثون عوضًا ذلك عن محتوى يقارن مباشرةً بين البائعين أو العلامات التجاريّة ويسمح لهم بالتوصّل إلى استنتاجهم الخاصّ حول ما هو "الأفضل" حقًا. أو كما عبّر عنه "ويل": الآن، وبعد أنْ عرفت ما يبحث عنه عملاؤك بالفعل، ما هي الخطوة التالية؟ أنشئ محتوىً يكرّر هذه النتائج الرئيسيّة توضّح الصورة أدناه ما تبدو عليه إحدى نتائج البحث الرئيسيّة للعبارة "أفضل برنامج لإدارة علاقات العملاء (CRM)": مصدر الصورة Wil’s CTAConf talk استلهمت "هابسبوت - HubSpot" فكرةً من هذا المقال لمجلّة "بي سي - PCMag"، وأعادت إنشاء جدولٍ خاصٍ بها يقارن حلولها مع بعض حلول منافسيها: مصدر الصورة Wil’s CTAConf talk من خلال إنشائها لمخطط المقارنة هذا، تمنح عملاءها المحتملين نوع المحتوى الذي يبحثون عنه بالاستعانة بنوع المحتوى الذي طلبه زبائنها في هذه المرحلة من مسيرتهم. لاحِظ أنّ العاملين على "هابسبوت" وضعوا أنفسهم في المرتبة الثانيّة في الجدول. مَنْ من المسوّقين قد يضع نفسه في المرتبة الثانية؟ ما هذه الجرأة! عادةً ما نرى المسوّقين يصيحون بأعلى الصوت، "نحن الأوائل!" بحيث يشعر المستهلكون بالاقتناع باستمرار. وكما يشير "ويل" في هذه الحالة، بأنّ القائمين على "هابسبوت" يخاطرون بعدم ادّعائهم بأنّهم الأوائل. ولكنّهم يضعون احتياجات العميل أوّلاً ، وهذا شيءٌ يحبّه الزبائن بالتأكيد —وكذلك الأمر بالنسبة لغوغل. 2: مربع "يسأل الناس أيضاً" إنّ مربّع غوغل "يسأل الناس أيضاً - People Also Ask" هو منجم ذهبٍ للمعلومات لتوقّع الشيء المقبل الذي سيبحث عنه عملاؤك. ميزة "يسأل الناس أيضًا"، وُضِعَت في عام 2015، وهي مربّع قابل للتوسيع يحتوي على طلبات بحثٍ ذات صلةٍ بالبحث الأصليّ. يمكن توسيع كلّ سؤال من خلال النقر عليه، ممّا يعطي المستخدم خياراتٍ لتحسين بحثه أو التعمّق أكثر في هذا الموضوع: مربعات "يسأل الناس أيضاً" تولّد مصدراً لانهائياً من الأسئلة ذات الصلة، وفي الحالة الموضّحة في الصورة فهي تقترح كلّ ما يتعلّق بالبيتزا. هذه الميزة يمكن أنْ تخبر المسوّقين الأذكياء عدّة أشياءٍ حول كيفيّة بحث المستخدمين، وتخلق فرصةً لحلّ مشاكل العملاء في العديد من المجالات. كيف تتمكّن من استخدام هذه الفكرة في التسويق؟ أجب عن المزيد من أسئلة المستخدمين الذين تستهدفهم أوضح "ويل" أنّه عندما تبحث عن أفكارٍ جديدةٍ للمحتوى، يمكن أنْ يكون مربّع "يسأل الناس أيضًا" مصدراً دائمًا للإلهام. ابدأ بكتابة طلبات البحث الشائعة لنشاطك الصناعيّ، ولاحِظ الأشياء الأخرى التي تظهر في مربّع "يسأل الناس أيضًا". تستند الاقتراحات الواردة في هذا المربّع إلى طلبات البحث المتكرّرة، لذا فهي رهانٌ رابحٌ لاستراتيجيّة المحتوى الخاصة بك. كما يقدم مربّع "يسأل الناس أيضًا" فرصةً لك لتكون رائدًا في أيّ موضوع. تخيّل لو كان موقعك بالتصيف 0 أو 1، وموجود في نتائج مربّع "يسأل الناس أيضًا"؟ سيتمّ توجيه كلّ المستخدمين إلى المحتوى الخاصّ بك. مصدر الصورة Wil’s CTAConf talk النتائج في مربّعات "يسأل الناس أيضًا" تكون عادةً نتائج مرتّبة في الصفحة الأولى من نتائج البحث عن عبارةٍ محددة. وللتفوّق على منافسيك في هذه الحالات، يجب أن تركّز على إنشاء محتوىً عالي الجودة، وأنيقٌ، وثريٌ بالمعلومات لكل طلب بحث. اكتسب خبرةً أكبر في مجال الشرائح المنبثقة (pop-up) سنتخذ الآن خطوةً متقدمةً إلى الأمام أبعد من إنشاء محتوىً متعلقٍ بعمليات البحث ذات الصلة، من خلال دخولك في مجال إنشاء المحتوى الذي يوجّه عملاءَك خلال مسيرتهم. وفي حديثه، شرح "ويل" أنّ مربّعات "يسأل الناس أيضًا" تعطيك إشاراتٍ حول كيفيّة توجيه إمكانيات فريق عملك: لأن الأسئلة ذات الصلة التي تأتي في مربّع "يسأل الناس أيضًا" هي الأشياء التي يقوم المستخدمون الآخرون بالنقر عليها بالفعل، حيث تمكّنك من وضع افتراضات حول نوع الأشياء التي يرغب عملاؤك في رؤيتها لاحقًا. على سبيل المثال، وجد القائمون على "سير" أنّه بعد قراءة دليل أداتهم "SEMRush "، كان العديد من العملاء يطلبون أيضًا مقارنةً بين "SEMRush " و"Moz". أخذ القائمون على "سير" هذه المعلومات وأنشأوا دليلاً يقارن بين الأداتين. ثمّ قاموا بإضافة شريحةٍ منبثقةٍ لمقالهم دليل أداة "SEMRush"، التي يمكنك رؤيتها في الصورة أدناه، مقدّمين للقارئ خيارًا لقراءة المقارنة لاحقًا. مصدر الصورة Wil’s CTAConf talk لم يعد القارئ بحاجةٍ للعودة إلى غوغل للعثور على المعلومات التي يريدها بعد ذلك، لأن "سير" قد أظهرتها لهم بالفعل. من خلال توقّع ما يطلبه عملاؤهم، القائمون على "سير" قادرون على إبقاء القرّاء في موقعهم، وجعلهم يجيبون على المزيد من أسئلتهم وبذلك يجعلونهم مصدرًا أجدر بالثقة. ضع الإعلانات في مواقع موثوقة لقد رأينا أنّ النتائج في مربّعات "يسأل الناس أيضًا" هي عادةً محتوىً عالي الجودة، وغنيّ بالمعلومات، ويكون مصنّفًا في الصفحة الأولى من قبل غوغل. وهذا يعني أنّ هذه المواقع موثوقة جدّاً من قبل غوغل، وأنها تظهر لطلبات البحث هذه، لذا هناك احتمال كبير بأن يزور عملاؤك مواقع الويب هذه في مرحلة ما من مراحل بحثهم. ويؤدي ذلك إلى إتاحة فرصةٍ جديدةٍ لاستهداف عملائك بإعلاناتٍ صوريّةٍ على المواقع التّي تتوقّع زيارتهم لها. ولتحقيق ذلك، أوضح "ويل"، ابحث في نتائج "يسأل الناس أيضًا" للعثور على المواقع التي تأتي كأهم الإجابات لجميع الاستفسارات المتعلّقة بكلمتك المفتاحية. بعد حصولك على قائمة بالمواقع، استخدم أداة مخطط عرض غوغل (Google’s Display planner) للعثور على هذه المواقع والحصول على فكرةٍ عن عدد مرّات الظهور التي ستحصل عليها. ثم أنشئ إعلاناتٍ صوريةً على المواقع التي تحقّق أكبر عدد ممكن من المشاهدات. يحب غوغل حلّاليّ المشاكل وبما أنّ غوغل يصبح أفضل وأفضل في فهم ما يريده الناس، فسينبغي على المسوقين اتّباع نهجٍ يضع حل مشكلات عملائهم أولاً. لحسن الحظّ، بدأت غوغل بالفعل في ترك أدلّة عمّا يريد عملاؤك طلبه حقاً من شركتك. باستخدامك لهذه الاقتراحات لبدء اتخاذ إجراءات وعرضها على عملائك في كل خطوة من مسيرتهم ستحتل مكانًا متقدمًا في طليعة العاملين في هذا المجال. ترجمة -وبتصرّف- للمقال Google Is Leaving You Clues to Help You Rank Higher لصاحبه Kayli Barth حقوق الصورة البارزة محفوظة لـ Freepik

سنتحدث في هذا الدرس عن محتوى قائمة الأدوات في تطبيق مستندات جوجل. تحتوي هذه القائمة على بعض الخيارات والأدوات المفيدة منها التدقيق الإملائي والاستكشاف والكتابة بالصوت وتدوين الملاحظات في المفكرة والتفضيلات. التدقيق الإملائي يُستعمل هذا الخيار للبحث عن الأخطاء الإملائيَّة في المستند وتصحيحها. صراحةً، القاموس الذي يوفِّره التطبيق ليس ذو كفاءة عالية وقد تجد أنَّه يشير لبعض الكلمات على أنَّها خاطئة وهي صحيحة مثل إضافة حرف زائد للكلمة (الواو أو الفاء) لذا لا تعتمد كل الاعتماد عليه في تدقيق المستند. عندما يضع التطبيق خطًّا أحمرًا تحت كلمة صحيحة يمكنك الضغط عليها بالزر الأيمن واختيار "إضافة إلى القاموس الشخصي". توضح الصورة التالية إحدى الكلمات التي وُضِعَ تحتها خط باعتبارها خاطئة، والكلمة هي "فالتنبيه" لذا نضيفها إلى القاموس الشخصي. يمكن أيضًا اختيار "تجاهل الكل" أي التجاهل في كل مرة تُكتب فيها هذه الكلمة أو تصحيحها أينما وردت إلى الكلمة المقترحة. القاموس الشخصي هو قاموس محلي خاص بك يمكنك أن تضيف فيه جميع الكلمات التي تراها صحيحة وهو شبيهٌ بخيار "إضافة إلى القاموس" في التطبيقات المشابهة. يمكن الإطلاع على محتوى القاموس الشخصي وإضافة الكلمات الجديدة أو التي تختارها من قائمة أدوات ← القاموس الشخصي. مراجعة التعديلات المقترحة سبق وأن تحدثنا في الدرس السابق (كيفية المشاركة في كتابة وتعديل مستند باستعمال مستندات جوجل) عن هذا الخيار وهو عرض التعديلات التي أجراها الآخرون الذين يشاركونك المستند وقبولها أو رفضها والتعليق عليها. البحث عن كلمة أو شرح لها إذا كنت تكتب أو تقرأ حول أمر معين وأنت ضمن مستندات جوجل وصادفك مصطلح أو جملة تريد البحث عنها أو تعريفها ومعرفة الكلمة المرادفة لها فماذا تفعل؟ تنتقل بالتأكيد إلى أحد محركات البحث وتكتب العبارة ضمنه وتبحث عنها. توقف قليلًا فأنت في تطبيق مستندات جوجل ولدى شركة جوجل محرك بحث لذا لن تضطر إلى الانتقال إلى نافذة أو صفحة أخرى بعد الآن. وظيفة خيار "الاستكشاف" هو البحث عن العبارة المحدَّدة في محرك البحث جوجل، وبضغطة رز واحدة تُعرض النتائج في قائمة تظهر على الطرف الأيسر. يُبحث عن العبارة المطلوبة في الويب والصور وحساب درايف الخاص بك. هنالك تسهيل كبير للوصول إلى هذه الأداة وذلك من ثلاثة مواقع: أولها عبر أدوات ← استكشاف، ومن القائمة عند الضغط بالزر الأيمن بعد تحديد أي جملة، ومن مربع صغير موجود أسفل يسار النافذة. تقتصر وظيفة الخيار "تعريف" في قائمة الأدوات على البحث عن معنًى للكلمة المحدَّدة وتعريفها بالإضافة إلى البحث عن كلمات مرادفة لها. إظهار مخطط المستند وعدد كلماته يُستعمل الخيار "مخطط المستند" لعرض عناوين فقرات المستند بحيث يسهل التنقل بينها والوصول إلى عنوان معيَّن بسرعة، ويشبه إلى حد ما جدول المحتويات. تظهر قائمة بالعناوين عند الضغط على خيار "مخطط مستند" في الطرف الأيسر تشبه القائمة الموضحة بالصورة. يمكن معرفة بعض المعلومات عن المستند بمساعدة الخيار "عدد الكلمات" مثل عدد صفحات المستند، وعدد الكلمات، والأحرف مع المسافات، والأحرف دون مسافات. إن استعملت تطبيقات أوفيس (Microsoft office) أو ليبر أوفيس (LiberOffice) فإنَّ هذه المعلومات تُعرض ضمن شريطٍ في الأسفل. الكتابة بالصوت يوفر تطبيق مستندات جوجل خدمة الكتابة بالصوت الشبيهة بتلك الموجودة في الهواتف المحمولة ذات نظام آندرويد (Andriod). حقيقةً، تحوي خدمة الكتابة بالصوت في هذا التطبيق مزايا كثيرة، منها الأوامر الصوتيَّة، ولكنَّها متوافرة باللغة الإنجليزية فقط. يدعم جوجل اللغة العربيَّة الفصحى بالإضافة إلى لهجات بعض الدول العربيَّة وهي الجزائر والبحرين ومصر والأردن والكويت ولبنان والمغرب وعمان وفلسطين وقطر والسعودية وتونس والإمارات. حاول عندما تتحدث أن يكون الصوت واضحًا وخاليًا من التشويش وبعيدًا عن الضجيج وأن تكون سرعة التحدث معتدلة ولا تتحدث بعُجالة. تفحَّص الميكروفون قبل البدء وإن لم يعمل جيدًا جرب استعمال ميكروفون خارجي (إن كنت تستعمل هاتفك أو حاسوبًا محمولًا). دوِّن ملاحظاتك عبر مفكرة keep لا بدَّ وأنت تكتب مقالة ما أو بحثًا أو أي شيء أن تنبثق بعض الملاحظات التي لا ترغب أن تنشغل بها خوفًا من التشويش، أو تريد تدوينها بغية الرجوع إليها لاحقًا، أو بعض الأفكار التي لمعت في ذهنك وتريد إضافتها للمستند بعد حين لذا لا تخف إن صادفك ذلك ولا داعي لوضع أوراق الملاحظات بجانبك. يوفِّر مستندات جوجل خدمة استعمال تطبيق google keep الذي هو أحد تطبيقات جوجل ووظيفته هي حفظ الملاحظات ومزامنتها مع حسابك ثمَّ الرجوع إليها وتعديلها أو الإضافة عليها أينما كنت وفي أي وقتٍ تريد لذا وداعًا لورق الملاحظات (sticky note). هنا تأتي الكفاءة، إذ تُحفظ ملاحظاتك في keep وتُعرض أيضًا في مستندات جوجل عند الضغط على "مفكرة keep". توضح الصورة السابقة أنَّ الملاحظة الأولى والثانية مرتبطة بالمستند بينما الملاحظة الثالثة هي ملاحظة عامة أضيفت إلى keep مباشرةً. يمكن كتابة ملاحظة ثمَّ الرجوع إليها بعد فترة وإضافتها إلى المستند بالضغط على الخيارات ثمَّ "إضافة إلى المستند" لإدراجها في موقع المؤشر. ترجمة المستند إلى لغات أخرى لا يخفى على أي شخص يستعمل منتجات جوجل خدمات الترجمة التي تتيحها سواءً بطريقة مباشرة عبر موقع ترجمة جوجل (google translate) وتطبيقات الترجمة أو غير المباشرة مثل أداة الترجمة الموجودة في متصفح كروم أي الرسالة التي يسألك فيها إن كنت تريد ترجمة هذه الصفحة إلى لغتك أو لغة أخرى أو ترجمة المنشورات من لغة إلى أخرى على مواقع التواصل الاجتماعي تلقائيًّا. عند الضغط على "ترجمة مستند" تظهر رسالة تخبرك بإنشاء مستند جديد يحمل اسمًا ما وخيارًا في أسفله تختار منه اللغة التي تريد الترجمة إليها. لا يمكن الاعتماد على هذه الأداة لترجمة مستند إن كنت تود ترجمته ترجمة جيِّدة خالية من الأخطاء وتنقل مضمون المحتوى نقلًا صحيحًا. محرر النص البرمجي عند الضغط على "محرر النص البرمجي" تُفتح صفحة جديدة ثمَّ تنتقل إلى تطبيق Google Script لإنشاء مشروع جديدة عليه. إنَّ هذا التطبيق هو لغة سكربت مبني بالاعتماد على لغة جافا سكربت، وإذا أردت استعماله فلن تضطر لتثبيت أي شيء على حاسوبك وستستعمل متصفحك فقط لكتابة الأكواد وتشغيلها على خواديم جوجل. إنَّ تطبيق google script متعدِّد الجوانب والاستعمالات ويمكنك بوساطته: إضافة القوائم ومربعات الحوار والأشرطة الجانبيَّة. نشر المستندات بشكل مستقل أو عبر جوجل. التواصل والتفاعل مع مختلف خدمات جوجل. تصميم وتطوير إضافات ونشرهم. التفضيلات تحتوي التفضيلات على خيارات تسرِّع من أداء المستخدم أثناء الكتابة مثل استعمال علامات الاقتباس الذكيَّة واكتشاف الروابط وتعيين اتجاه الفقرة تلقائيًّا والبديل التلقائي الذي هو أهمها. أحيانًا تريد إدراج بعض الرموز أو الأسهم أو حتى كسر واحد مثلًا ولفعل ذلك تتوقف عن الكتابة وتدرج رمزًا أو معادلة وسيأخذ ذلك بعض الوقت؛ تأتي هنا الفائدة من خيار "البديل التلقائي" إذ يمكنك إدراج سلسلة من الأحرف والرموز وسيُستبدل بها رمزًا تختاره أنت تلقائيًّا مثل عند كتابة (c) فيستبدل بها الرمز © وهكذا. توجد خيارات استبدال افتراضيَّة ويمكنك أيضًا أن تضيف لها ما تشاء.