כניסה ל-Kubernetes: EFK נגד PLG

ניטור הפך למרכיב חשוב מאוד בצמיחה של פתרונות ענן ככל שהמורכבות של מערכות מבוזרות עולה. יש צורך להבין את ההתנהגות שלהם. אנו זקוקים לכלים ניתנים להרחבה שיכולים לאסוף נתונים מכל השירותים - ולספק למומחים ממשק אחד עם ניתוח ביצועים, הדגמת שגיאות, זמינות ויומנים.

אותם כלים חייבים להיות יעילים ופרודוקטיביים. במאמר זה, נבחן שתי ערימות טכנולוגיה פופולריות: EFK (Elasticsearch) ו-PLG (Loki) ונבחן את הארכיטקטורות וההבדלים שלהן.

מחסנית EFK

אולי כבר שמעתם על ה-ELK או EFK הפופולריים מאוד. הערימה מורכבת מכמה חלקים נפרדים: Elasticsearch (אחסון אובייקטים), Logstash או FluentD (איסוף וצירוף יומנים) ו-Kibana להדמיה.

זרימת עבודה טיפוסית נראית כך:

Elasticsearch - אחסון אובייקטים מבוזר עם חיפוש וניתוח בזמן אמת. פתרון מצוין לנתונים חצי מובנים כגון יומנים. המידע נשמר כמסמכי JSON, מתווסף בזמן אמת ומופץ על פני צמתי אשכול. נעשה שימוש באינדקס הפוך, המכיל את כל המילים הייחודיות והמסמכים המשויכים לחיפוש בטקסט מלא, אשר בתורו מבוסס על מנוע החיפוש Apache Lucene.

שוטףD הוא אוסף נתונים המאחד נתונים בעת איסוף וצריכה שלהם. הוא מנסה לארגן את הנתונים ב-JSON ככל האפשר. הארכיטקטורה שלו ניתנת להרחבה, יש עוד מאות הרחבות שונות, בתמיכת הקהילה, לכל אירוע.

קיבאנה - כלי להדמיית נתונים עבור Elasticsearch עם יכולות נוספות שונות, למשל ניתוח סדרות זמן, ניתוח גרפים, למידת מכונה ועוד.

ארכיטקטורת Elasticsearch

נתוני אשכול Elasticsearch מאוחסנים בפריסה על פני כל הצמתים שלו. אשכול מורכב ממספר צמתים כדי לשפר את הזמינות והגמישות. כל צומת יכול לבצע את כל התפקידים של האשכול, אבל בפריסות בהיקף גדול, לצמתים מוקצות בדרך כלל משימות בודדות.

סוגי צומת אשכול:

• צומת מאסטר - מנהל את האשכול, יש צורך בשלושה לפחות, אחד תמיד פעיל;
• צומת נתונים - מאחסן נתונים באינדקס ומבצע איתם משימות שונות;
• ingest node - מארגן צינורות להמרת נתונים לפני האינדקס;
• תיאום צומת - ניתוב בקשות, צמצום שלב עיבוד החיפוש, תיאום אינדקס המוני;
• צומת התראה - הפעלת משימות התראה;
• צומת למידת מכונה - עיבוד משימות למידת מכונה.

התרשים שלהלן מראה כיצד נתונים מאוחסנים ומשכפלים על פני צמתים כדי להשיג זמינות נתונים גבוהה יותר.

הנתונים של כל רפליקה מאוחסנים באינדקס הפוך, התרשים שלהלן מראה כיצד זה קורה:

התקנה

ניתן לראות פרטים כאן, אני אשתמש בתרשים ההגה:

$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elastics

מחסנית PLG

אל תתפלאו אם לא תמצאו את ראשי התיבות האלה, מכיוון שהוא ידוע יותר בשם Grafana Loki. בכל מקרה, מחסנית זו צוברת פופולריות מכיוון שהיא משתמשת בפתרונות טכניים מוכחים. אולי כבר שמעתם על Grafana, כלי הדמיה פופולרי. יוצריה, בהשראת פרומתאוס, פיתחו את Loki, מערכת צבירת יומנים בעלת ביצועים גבוהים הניתנת להרחבה אופקית. לוקי אינדקס רק את המטא-נתונים, לא את כתבי העת עצמם, פתרון טכני המאפשר את זה קל לשימוש וחסכוני.

פרומטייל - סוכן לשליחת יומנים ממערכת ההפעלה לאשכול Loki. גרפנה הוא כלי הדמיה המבוסס על נתונים של לוקי.

לוקי בנוי על אותם עקרונות כמו פרומתאוס, מה שהופך אותו למתאים היטב לאחסון וניתוח יומני Kubernetes.

אדריכלות לוקי

ניתן להפעיל את Loki כתהליך בודד או כתהליכים מרובים, מה שמאפשר שינוי קנה מידה אופקי.

זה יכול לעבוד גם כיישום מונוליטי או כשירות מיקרו. הפעלה כתהליך בודד יכולה להיות שימושית לפיתוח מקומי או לניטור קטן. ליישום תעשייתי ועומס עבודה ניתן להרחבה, מומלץ להשתמש באפשרות המיקרו-שירות. הנתיבים לכתיבה ולקריאת נתונים מופרדים, כך שניתן לכוונן אותם ולהתאים אותם לפי הצורך.

בואו נסתכל על הארכיטקטורה של מערכת איסוף היומנים מבלי להיכנס לפרטים:

והנה התיאור (ארכיטקטורת מיקרו-שירות):

רכיבים:

פרומטייל - סוכן המותקן בצמתים (כמערכת של שירותים), הוא מסיר יומנים ממשימות וניגש ל-Kubernetes API כדי להשיג מטא נתונים שיתייגו את היומנים. לאחר מכן הוא שולח את היומן לשירות לוקי הראשי. מיפוי מטא נתונים תומך באותם כללי תיוג כמו פרומתאוס.

מפיץ - מפיץ שירותים שפועל כמאגר. כדי לעבד מיליוני רשומות, הוא אורז נתונים נכנסים, דוחס אותם בבלוקים כשהם מגיעים. מספר כיורי נתונים פועלים בו זמנית, אך יומנים השייכים לזרם נתונים נכנס אחד צריכים להופיע רק באחד מהם עבור כל הבלוקים שלו. זה מאורגן לטבעת של כיורים וגיבוב רציף. עבור סובלנות תקלות ויתירות, זה נעשה n פעמים (3 אם לא מוגדר).

אינגסטר - מקלט שירות. בלוקי נתונים מגיעים דחוסים עם יומנים שנוספו. ברגע שהגוש בגודל מספיק, הבלוק נשטף למסד הנתונים. מטא נתונים עוברים לאינדקס, ונתונים מבלוק היומן עוברים ל-Chunks (בדרך כלל אחסון אובייקטים). לאחר האיפוס, המקלט יוצר בלוק חדש שבו יתווספו ערכים חדשים.

מדד - מסד נתונים, DynamoDB, Cassandra, Google BigTable וכו'.

גושים - בלוקי יומן בצורה דחוסה, המאוחסנים בדרך כלל באחסון אובייקטים, למשל, S3.

שאילתה - נתיב הקריאה שעושה את כל העבודה המלוכלכת. הוא מסתכל על טווח הזמן וחותמת הזמן, ולאחר מכן בוחן את האינדקס כדי למצוא התאמות. לאחר מכן, הוא קורא בלוקים של נתונים ומסנן אותם כדי להשיג את התוצאה.

עכשיו בואו נראה הכל בפעולה.

התקנה

הדרך הקלה ביותר להתקין ב-Kubernetes היא להשתמש בהגה. אנו מניחים שכבר התקנת והגדרת אותו (והגרסה השלישית! משוער. מְתוּרגְמָן)

הוסף מאגר והתקן מחסנית.

$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=false

להלן לוח מחוונים לדוגמא המציג נתונים מ-Prometheus עבור מדדי Etcd ומ-Loki עבור יומני Pod Etcd.

עכשיו בואו נדון בארכיטקטורה של שתי המערכות, וגם נשווה את היכולות שלהן זו עם זו.

השוואה

שפת שאילתה

Elasticsearch משתמש ב-Query DSL ושפת שאילתות Lucene כדי לספק יכולות חיפוש בטקסט מלא. זהו מנוע חיפוש מבוסס וחזק עם תמיכת מפעילים רחבה. בעזרתו תוכלו לחפש לפי הקשר ולמיין לפי רלוונטיות.

בצד השני של הטבעת נמצא LogQL, בשימוש בלוקי, היורש של PromQL (שפת השאילתה של פרומתאוס). הוא משתמש בתגי יומן כדי לסנן ולבחור נתוני יומן. אפשר להשתמש בכמה אופרטורים ובחשבון כמתואר כאן, אבל מבחינת היכולות הוא מפגר אחרי שפה אלסטית.

מכיוון שאילתות בלוקי משויכות לתגיות, קל לתאם אותן עם מדדים, וכתוצאה מכך קל יותר לארגן איתן ניטור תפעולי.

מדרגיות

שתי הערימות ניתנות להרחבה אופקית, אך לוקי מקל על כך מכיוון שיש לה נתיבי קריאה וכתיבה נפרדים וארכיטקטורת מיקרו-שירות. ניתן להתאים אישית את Loki כדי להתאים לצרכים שלך וניתן להשתמש בו עבור כמויות גדולות מאוד של נתוני יומן.

ריבוי דירות

ריבוי דירות באשכול הוא נושא נפוץ בקיצור OPEX, שתי הערימות מספקות ריבוי דירות. יש כמה עבור Elasticsearch דרכים הפרדת לקוח: אינדקס נפרד לכל לקוח, ניתוב מבוסס לקוח, שדות לקוח ייחודיים, מסנני חיפוש. ללוקי יש לתמוך בצורה של כותרת HTTP X-Scope-OrgID.

עלות

לוקי חסכוני למדי בשל העובדה שהוא לא מוסיף את הנתונים, אלא רק את המטא נתונים. זה משיג חיסכון באחסון וזיכרון (מטמון), מכיוון שאחסון אובייקטים זול יותר מאחסון בלוק, המשמש באשכולות Elasticsearch.

מסקנה

ניתן להשתמש בערימת ה-EFK למגוון מטרות, לספק גמישות מרבית וממשק Kibana עשיר בתכונות לניתוח, הדמיה ושאילתות. ניתן לשפר זאת עוד יותר על ידי יכולות למידת מכונה.

מחסנית Loki שימושית במערכת האקולוגית של Kubernetes בגלל מנגנון גילוי המטא נתונים שלה. אתה יכול בקלות לתאם נתונים לניטור בהתבסס על סדרות זמן בגרפאנה וביומנים.

בכל הנוגע לעלות ולאחסון יומנים לטווח ארוך, Loki מהווה נקודת כניסה מצוינת לפתרונות ענן.

ישנן אלטרנטיבות נוספות בשוק - חלקן עשויות להיות טובות יותר עבורך. לדוגמה, ל-GKE יש אינטגרציה של Stackdriver המספקת פתרון ניטור מצוין. לא כללנו אותם בניתוח שלנו במאמר זה.

קישורים:

• https://github.com/grafana/loki/blob/master/docs/overview/comparisons.md
• https://www.elastic.co/blog/found-elasticsearch-from-the-bottom-up
• https://www.elastic.co/blog/found-elasticsearch-in-production/

המאמר תורגם והוכן להבר על ידי עובדים מרכז אימוני סלרם - קורסים אינטנסיביים, קורסי וידאו והכשרה ארגונית ממומחים מתרגלים (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

מקור: www.habr.com