איסוף בולי עץ מלוקי

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

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

מה זה לוקי

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

דף הבית, GitHub

לפני שאני נכנס למה שאתה יכול לעשות עם לוקי, אני רוצה להבהיר למה הכוונה ב"רעיון של הוספת מטא נתונים לאינדקס בלבד". הבה נשווה את גישת Loki ואת גישת האינדקס בפתרונות מסורתיים, כגון Elasticsearch, באמצעות דוגמה של שורה מיומן nginx:

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

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

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

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

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

חיפוש יומן

אתה יכול לחפש ביומנים בממשק מיוחד Grafana — Explorer. השאילתות משתמשות בשפת LogQL, שדומה מאוד ל-PromQL שבה משתמש פרומתאוס. באופן עקרוני, ניתן לחשוב עליו כ-grep מבוזר.

ממשק החיפוש נראה כך:

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

{image_name="nginx.promtail.test"} |= "index"

בגלל האופן שבו לוקי עובד, לא ניתן להגיש בקשות ללא בורר, אך ניתן להפוך את התוויות לגנריות באופן שרירותי.

הבורר הוא ערך המפתח של הערך בסוגרים מסולסלים. ניתן לשלב בוררים ולציין תנאי חיפוש שונים באמצעות האופרטורים =, != או ביטויים רגולריים:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev 

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

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

ניתן למצוא תיאור מלא של התכונות בתיעוד LogQL.

ניתוח יומן

ישנן מספר דרכים לאיסוף יומנים:

• בעזרת Promtail, רכיב סטנדרטי של המחסנית לאיסוף בולי עץ.
• ישירות ממיכל הדוקר באמצעות מנהל הלוגינג של לוקי דוקר.
• השתמש ב- Fluentd או Fluent Bit שיכולים לשלוח נתונים ללוקי. בניגוד ל-Promtail, יש להם מנתחים מוכנים כמעט לכל סוג של יומן והם יכולים להתמודד גם עם יומנים מרובי שורות.

בדרך כלל Promtail משמש לניתוח. זה עושה שלושה דברים:

• מוצא מקורות נתונים.
• צרף להם תוויות.
• שולח נתונים ללוקי.

נכון לעכשיו, Promtail יכול לקרוא יומנים מקבצים מקומיים ומיומן systemd. זה חייב להיות מותקן בכל מכונה שממנה נאספים יומנים.

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

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

1. שלבי ניתוח. זה השלב של RegEx ו-JSON. בשלב זה, אנו מחלצים נתונים מהיומנים לתוך המפה שנקראת שחולצה. אתה יכול לחלץ מ-JSON פשוט על ידי העתקת השדות שאנו צריכים לתוך המפה שחולצה, או באמצעות ביטויים רגולריים (RegEx), כאשר קבוצות עם שם "ממופות" למפה שחולצה. המפה שחולצה היא אחסון מפתח-ערך, כאשר מפתח הוא שם השדה, והערך הוא ערכו מהיומנים.
2. שינוי שלבים. לשלב זה יש שתי אפשרויות: טרנספורמציה, שבה אנו קובעים את כללי הטרנספורמציה, ומקור - מקור הנתונים לטרנספורמציה מהמפה שחולצה. אם אין שדה כזה במפה שחולצה, אז הוא ייווצר. כך, ניתן ליצור תוויות שאינן מבוססות על המפה שחולצה. בשלב זה, אנו יכולים לתפעל את הנתונים במפה שחולצה באמצעות שימוש חזק למדי תבנית גולנג. בנוסף, עלינו לזכור שהמפה שחולצה נטענה במלואה במהלך הניתוח, מה שמאפשר למשל לבדוק את הערך בה: "{{if .tag}tag value exists{end}}". התבנית תומכת בתנאים, בלולאות ובכמה פונקציות מחרוזות כגון Replace ו-Trim.
3. שלבי פעולה. בשלב זה, אתה יכול לעשות משהו עם החילוץ:
   • צור תווית מהנתונים שחולצו, שתוכנס לאינדקס על ידי לוקי.
   • שנה או הגדר את זמן האירוע מהיומן.
   • שנה את הנתונים (טקסט יומן) שיעברו ללוקי.
   • צור מדדים.
4. שלבי סינון. שלב ההתאמה, שבו נוכל לשלוח רשומות שאיננו צריכים ל-/dev/null, או לשלוח אותן לעיבוד נוסף.

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

לבדיקה, ניקח תמונת nginx jwilder/nginx-proxy:alpine שונה ודמון קטן שיכול לבצע שאילתות בעצמו באמצעות HTTP בתור nginx-proxy. לדמון יש כמה נקודות קצה, להן הוא יכול לתת תגובות בגדלים שונים, עם סטטוסים שונים של HTTP ועם עיכובים שונים.

נאסוף יומנים ממכולות docker, אותן ניתן למצוא לאורך הנתיב /var/lib/docker/containers/ / -json.log

ב-docker-compose.yml אנו מגדירים את Promtail ומציינים את הנתיב לתצורה:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

הוסף את הנתיב ללוגים ל-promtail.yml (יש אפשרות "דוקר" בתצורה שעושה את אותו הדבר בשורה אחת, אבל זה לא יהיה כל כך ברור):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

כאשר תצורה זו מופעלת, לוקי יקבל יומנים מכל הקונטיינרים. כדי להימנע מכך, אנו משנים את ההגדרות של test nginx ב-docker-compose.yml - הוסף רישום לשדה התג:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

ערוך את promtail.yml והגדר Pipeline. היומנים הם כדלקמן:

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

שלבי צינור:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

אנו מחלצים את שדות הזרם, attrs, attrs.tag (אם יש) מה-JSON הנכנס ומכניסים אותם למפה שחולצה.

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

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

 - labels:
     image_name:
     container_name:

אנו מחלקים תוויות. אם המפתחות image_name ו-container_name נמצאים בנתונים שחולצו, הערכים שלהם יוקצו לתוויות המתאימות.

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

אנו משליכים את כל היומנים שאין להם תוויות image_name ו-contain_name מוגדרים.

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

עבור כל היומנים ששם ה-image שלהם שווה ל-nginx.promtail.test, אנו מחלצים את שדה היומן מיומן המקור ומכניסים אותו למפה שחולצה בעזרת מקש השורה.

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

אנו מנקים את מחרוזת הקלט עם ביטויים רגולריים ושולפים את המארח הוירטואלי של nginx ואת שורת היומן של nginx.

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

ניתוח יומן nginx עם ביטויים רגולריים.

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

ניתוח request_url. בעזרת regexp, אנו קובעים את מטרת הבקשה: לסטטיקה, לתמונות, ל-API ולהגדיר את המפתח המתאים במפה שחולצה.

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

באמצעות אופרטורים מותנים ב-Template, אנו בודקים את השדות המותקנים במפה המחולצת ומגדירים את הערכים הנדרשים לשדה request_type: photo, static, API. הקצה אחר אם נכשל. כעת request_type מכיל את סוג הבקשה.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

אנחנו מגדירים את התוויות api_request, virtual_host, request_type ו-status (סטטוס HTTP) על סמך מה שהצלחנו לשים במפה שחולצה.

       - output:
           source: nginx_log_row

שנה פלט. כעת יומן ה-nginx הנוקה מהמפה שחולצה עובר ללוקי.

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

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

הדמיית יומן

לוקי יכול לשמש כמקור נתונים עבור תרשימי Grafana באמצעות LogQL. התכונות הבאות נתמכות:

• קצב - מספר רשומות בשנייה;
• ספירה לאורך זמן - מספר הרשומות בטווח הנתון.

יש גם פונקציות צבירה Sum, Avg ואחרות. אתה יכול לבנות גרפים מורכבים למדי, למשל, גרף של מספר שגיאות HTTP:

מקור הנתונים ברירת המחדל של לוקי הוא קצת פחות פונקציונלי ממקור הנתונים של פרומתאוס (לדוגמה, לא ניתן לשנות את המקרא), אבל את לוקי ניתן לחבר כמקור מסוג פרומתאוס. אני לא בטוח אם זו התנהגות מתועדת, אבל אם לשפוט לפי תגובת המפתחים "כיצד להגדיר את לוקי כמקור נתונים של פרומתאוס? · גיליון #1222 · grafana/loki", למשל, זה חוקי לחלוטין ולוקי תואם באופן מלא ל-PromQL.

הוסף את Loki כמקור נתונים עם סוג Prometheus והוסף כתובת URL /loki:

ואתה יכול לעשות גרפים, כאילו אנחנו עובדים עם מדדים מפרומתאוס:

אני חושב שהפער בפונקציונליות הוא זמני והמפתחים יתקנו את זה בעתיד.

מדדים

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

הוסף קטע נוסף ל-promtail.yml:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

האפשרות מאפשרת להגדיר ולעדכן מדדים על סמך נתונים מהמפה שחולצה. מדדים אלו אינם נשלחים ללוקי - הם מופיעים בנקודת הקצה Promtail /metrics. יש להגדיר את פרומתאוס לקבל נתונים משלב זה. בדוגמה שלמעלה, עבור request_type="api" אנו אוספים מדד היסטוגרמה. עם מדדים מסוג זה נוח לקבל אחוזונים. עבור סטטיות ותמונות, אנו אוספים את סכום הבתים ומספר השורות בהן קיבלנו בתים כדי לחשב את הממוצע.

קרא עוד על מדדים כאן.

פתח יציאה ב-Promtail:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

אנו מוודאים שהמדדים עם הקידומת promtail_custom הופיעו:

הקמת פרומתאוס. הוסף פירוט עבודה:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

ותצייר גרף:

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

שינוי קנה מידה

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

ניתן לאחסן נתחים באחסון תואם S3, וניתן להשתמש בבסיסי נתונים הניתנים להרחבה אופקית לאחסון אינדקסים: Cassandra, BigTable או DynamoDB. חלקים אחרים של Loki - מפיצים (לכתיבה) ו-Querier (לשאילתות) - הם חסרי מדינה והם גם מותאמים לרוחב.

בכנס DevOpsDays Vancouver 2019, אחד המשתתפים Callum Styan הודיע ​​כי עם לוקי לפרויקט שלו יש פטה-בייט של יומנים עם אינדקס של פחות מ-1% מהגודל הכולל: "כיצד לוקי מתאם מדדים ויומנים - וחוסך לך כסף".

השוואה של לוקי ו-ELK

גודל אינדקס

כדי לבדוק את גודל האינדקס שהתקבל, לקחתי יומנים ממיכל nginx שעבורו הוגדר ה-Pipeline לעיל. קובץ היומן הכיל 406 שורות בנפח כולל של 624 MB. יומנים נוצרו תוך שעה, בערך 109 רשומות בשנייה.

דוגמה לשתי שורות מהיומן:

כאשר הוכנס לאינדקס על ידי ELK, זה נתן גודל אינדקס של 30,3 MB:

במקרה של לוקי, זה נתן כ-128 KB של אינדקס וכ-3,8 MB של נתונים בנתחים. ראוי לציין כי היומן נוצר באופן מלאכותי ולא כלל מגוון רחב של נתונים. gzip פשוט ביומן ה-JSON המקורי של Docker עם נתונים נתן דחיסה של 95,4%, ובהתחשב בכך שרק יומן ה-nginx הנוקה נשלח ללוקי עצמו, הדחיסה ל-4MB מובנת. המספר הכולל של ערכים ייחודיים עבור תוויות לוקי היה 35, מה שמסביר את הגודל הקטן של המדד. עבור ELK, גם היומן נוקה. לפיכך, לוקי דחס את הנתונים המקוריים ב-96%, ו-ELK ב-70%.

צריכת זיכרון

אם נשווה את כל הערימה של פרומתאוס ו-ELK, אז לוקי "אוכל" פי כמה פחות. ברור ששירות Go צורך פחות משירות Java, והשוואת גודל ה-Heap Elasticsearch JVM והזיכרון שהוקצה ל-Loki אינה נכונה, אך עם זאת, ראוי לציין שלוקי משתמש בהרבה פחות זיכרון. יתרון המעבד שלו לא כל כך ברור, אבל הוא גם קיים.

מהירות

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

חיפוש יומן

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

ממשק

ראשית, זה יפה (סליחה, לא יכולתי להתאפק). ל-Grafana יש ממשק נחמד למראה, אבל ל-Kibana הרבה יותר פונקציונלי.

לוקי יתרונות וחסרונות

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

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

מסקנה

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

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

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

המאגר עם הקוד המשמש במאמר נמצא כאן.

מקור: www.habr.com