למה לעזאזל יכולת התצפית כל כך יקרה!?

פעל עכשיו! מבצע לזמן מוגבל! המפעילים עומדים מנגד! אני מוכן להרפתקה הבאה שלי בתור עורך דין DevRel / מבשר טכני / IT Talespinner. אם זה נשמע כמו משהו שאתה צריך, פנה אליי במייל או בלינקדאין אני מתמחה בניטור וצפיות כבר 27 שנים, וראיתי הרבה כלים וטכניקות באים והולכים (RMon, מישהו?); ויותר מכמה באים ונשארים (השמועות על מותו של SNMP היו - ועדיין - מוגזמות מאוד.). לאחרונה חקרתי את אחד השיפורים האחרונים במרחב - OpenTelemetry (שאני מקצר ל"OTel" בהמשך הבלוג הזה). . כתבתי על ההחלטה שלי לצלול ל-OTel לאחרונה לרוב, אני נהנה מהמסע. אבל יש בעיה שקיימת עם צפייה כבר זמן מה, וזה משהו ש-OTel לא עוזר. הכותרת של הפוסט הזה מרמזת על הנושא, אבל אני רוצה להיות יותר מפורשת. נתחיל בקצת השוואה בין קניות. לפני שאעצבן כל ספק בעיר, אני רוצה להבהיר שאלו מספרים רחבים, גסים וברמה גבוהה. קישרתי לדפי התמחור אם אתה רוצה לבדוק את הפרטים, ואני מאשר שמה שאתה רואה למטה לא בהכרח מעיד על המחיר שאתה עשוי לשלם בפועל לאחר קבלת הצעת מחיר על סביבת ייצור אמיתית. של שריד חדש חיובים 35¢ לג'יגה-בייט עבור כל נתונים שתשלח להם. ...למרות לא מבהיר זאת במיוחד שדף התמחור ל-Datadog יש רשימת כביסה אמיתית של אפשרויות, אבל ברמה גבוהה הם : גובים $15-$34 למארח 60¢ - $1.22 למיליון רשומות תזרים נטו $1.06-$3.75 למיליון רשומות יומן $1.27-$3.75 למיליון טווחים של Dynatrace כולל רשימה ארוכה כמעט כמו של Datadog, אבל כמה פריטים מרכזיים: דף התמחור 15¢ לכל 100,00 מדדים בתוספת .07¢ לכל הופעה ליום לשמירה 2¢ לכל הופעה עבור יומנים בתוספת 0.07¢- לכל הופעה ליום כדי לשמור אותם בתוספת 0.035¢ לכל הופעה שאילתה לאירועים יש אותו קצב כמו יומנים ‎.014¢ לכל 1,000 טווחים Grafana, שהוא – יש לציין – הוא קוד פתוח ומעניק לך למעשה הכל בחינם אם אתה מוכן לעשות את המשימות הכבדות של התקנה ואירוח. אבל : ניתן לסכם את התמחור שלהם כך $8.00 עבור 1,000 מדדים, (עד 1/דקה) 50¢ לכל הופעה עבור יומנים ומעקב אחריהם, עם שמירה של 30 יום רשימה זו אינה ממצה ואינה מלאה. עזבתי הרבה ספקים, לא בגלל שגם להם אין תמחור מבוסס צריכה אלא בגלל שזה יהיה יותר מאותו הדבר. אפילו עם אלה שלמעלה, הפרטים כאן אינם מלאים. חברות מסוימות גובות לא רק תשלום עבור צריכה (בליעה), הן גם גובות על מנת לאחסן את הנתונים, וגובות שוב כדי לחפש את הנתונים (מסתכל בך, New Relic). חברות מסוימות דוחפות אותך לבחור דרג של שירות, ואם לא תעשה זאת, הן יגבו ממך תעריף משוער על סמך האחוזון ה-99 של השימוש לחודש ( ). מסתכל עליך, Datadog זה לא צריך להפתיע אף אחד שמה שמופיע בדף התמחור שלהם הוא אפילו לא המילה האחרונה. חלק מהחברות הללו בוחנות, אפילו עכשיו, להגדיר מחדש את הפרשנות שלהן למושג "תמחור מבוסס צריכה" שעשוי להפוך את הדברים לאטומים עוד יותר (מסתכל בך שוב, New Relic). אפילו עם כל זה נאמר, אני יוצא לדרך וקובע לפרוטוקול שכל אחת ואחת מנקודות המחיר האלה כל כך נמוכות שאפילו המילה "טריוויאלית" גדולה מדי. כלומר, עד שעומסי הייצור יעמדו בגיליון התמחור. בשלב זה המספרים הקטנים האלה מסתכמים לכסף אמיתי, ומהר. הרבים של אנקדוטה שלחתי את השאלה הזו לכמה חברים, ושאלתי אם היו להם חוויות הלם מדבקות בעולם האמיתי. כמו תמיד, החברים שלי לא אכזבו. "עשיתי השוואת מחירים מפורטת של New Relic עם Datadog לפני כמה שנים עם Fargate כשימוש העיקרי. New Relic היה זול משמעותית עד שהתחלת לשלוח יומנים ואז Datadog היה פתאום זול ב-30-40% אפילו עם apm. [אבל] העלות שלהם לכל מארח גם מביאה בחשבון והופכת את APM לבלתי אטרקטיבית אלא אם כן אתה עושה משהו ללא שרת. רצינו להשתמש בו ב-kubernetes אבל זה היה כל כך יקר, שההנהלה סירבה להאמין לעלויות עם שירותים ב-Fargate אז בדרך כלל הצגתי את המספרים שלי כל 2-3 חודשים."__- אוולין אוסמן, ראש הפלטפורמה ב-enmacc "כל מה שיש לי זה את הזיכרון של פרצופו של מנהלי הכספים כשהוא ראה את הצעת החוק."__– מישהו שמעדיף להישאר אנונימי, למרות שהציטוט הזה אפי להחריד. וכמובן יש את המסתורין (הידוע לשמצה כיום, בחוגי צפייה) היחיד של . שטר ה-Datadog של 65 מיליון דולר הצעד הראשון הוא להודות שיש לך בעיה פעם (שאני מתכוון לתחילת שנות ה-2000), האתגר עם ניטור (צפיות לא היה מונח שהשתמשנו בו עדיין) היה איך לזהות את הנתונים שאנחנו צריכים, ואז לגרום למערכות לוותר על הנתונים האלה, ואז לאחסן את הנתונים האלה בצורה שאפשרה (שלא לדבר על יעילה) להשתמש בשאילתות, תצוגות, התראות וכדומה. שם כמעט כל העלות נחה. המערכות עצמן היו במקום וברגע שהחומרה נקנתה, למעשה "חינם". התוצאה הייתה שהנוהג המקובל היה לאסוף כמה שיותר ולשמור אותו לנצח. ולמרות השינוי בטכנולוגיה, החשיבה של ארגונים רבים נותרה זהה. אדריכל Grafana Solutions Alec Isaacson מציין שהשיחות שלו עם לקוחות מתרחשות לפעמים כך: "אני אוסף מדי 5 שניות מדדי CDM מהמערכות הכי קריטיות שלי, כי פעם, לפני הרבה זמן, מישהו זכה לצעקות כשהמערכת הייתה איטית והמדדים לא אמרו לו למה." כיום, איסוף נתוני ניטור וצפיות ("טלמטריה") הוא קל יחסית, אבל - הן כיחידים והן כארגונים - לא שינינו את מסגרת הבעיה שלנו. אז אנחנו ממשיכים לתפוס כל פיסת נתונים הזמינה לנו. אנחנו מכינים את הקוד שלנו עם כל תג וטווח שאנחנו יכולים לחשוב עליהם; אם יש הודעת יומן, אנו שולחים אותה; מדדי חומרה? עדיף לתפוס אותו כי זה יספק הקשר; אם יש טלמטריית רשת (NetFlow, יומני זרימה של VPC, טלמטריה זרימה) אנחנו מוצצים גם את זה. אבל אנחנו אף פעם לא לוקחים את הזמן לחשוב מה אנחנו הולכים לעשות עם זה. הניסיון של גב' אוסמן ממחיש את התוצאה: "[להם] לא היה מושג מה הם עושים עם ניטור […] כל המכשור והרישום היו מופעלים ואז הייתה שמירה ממושכת "למקרה". אז הם פשוט שרפו כמויות מגוחכות של כסף" כדי לחבר את זה להתנהגות רעה נוספת ששברנו את עצמנו ממנה (פחות או יותר): בימים הראשונים של "הרמה והסטה" (לעתים קרובות מתואר בצורה מדויקת יותר כ"הרמה וחרא") לענן, לא רק העברנו יישומים לסיטונאי; העברנו אותו למערכות הגדולות ביותר שהפלטפורמה הציעה. מַדוּעַ? כי בהקשר ה-on prem הישן יכולת לבקש שרת רק פעם אחת, ולכן ביקשת את הדבר הכי גדול שיכולת לקבל, כדי להוכיח את ההשקעה שלך בעתיד. ההחלטה הזו התבררה לא רק כנאיבית בצורה משעשעת, היא הייתה יקרה להחריד ולקח לכולם כמה שנים להבין איך "מחשוב אלסטי" עובד ולעצב מחדש את היישומים שלהם לפרדיגמה החדשה. כמו כן, הגיע הזמן שנכיר ונכיר בכך שאיננו יכולים להרשות לעצמנו לאסוף כל פיסת נתוני טלמטריה הזמינים לנו, ויתרה מכך, שאין לנו תוכנית לנתונים אלה גם אם הכסף לא היה אובייקט. תודו בזה: גם לבעיה שלכם יש בעיה תן לי לעבור ל-OTel לרגע. אחת הסיבות העיקריות - אולי הסיבה העיקרית - לעבור אליה היא להסיר, לתמיד ולתמיד, את הכאב של נעילת ספקים. זה משהו שחקרתי והדהד לאחרונה על ידי חבר שלי: בפוסט האחרון שלי בבלוג - מאט מקדונלד-וואלאס, אדריכל פתרונות, מעבדות גרפאנה OTel אכן פותר הרבה מהבעיות סביב "אוי נהדר! עכשיו אנחנו לכודים עם הספק x וזה הולך לעלות לנו מיליונים לשחזר את כל הקוד הזה" בניגוד ל"אה, אנחנו מחליפים ספקים? מגניב, תן לי רק לעדכן את נקודת הקצה שלי..." שיהיה ברור מאוד, OTel עושה עבודה מדהימה בפתרון הבעיה הזו, שהיא מדהימה בפני עצמה. אבל... יש חסרון ב-OTel שאנשים לא שמים לב אליו מיד, אם הם מבחינים בו בכלל. בעיה זו מחמירה את הבעיה הקודמת עוד יותר. OTel לוקח את כל הנתונים שלך (מדדים, יומנים, עקבות וכל השאר), אוסף אותם ושולח אותם לכל מקום שאתה רוצה שיגיע. אבל OTel לא תמיד עושה את זה ביעילות. דוגמה 1: הודעות יומן בואו ניקח את הודעת היומן למטה, שמגיעה ישר מה-syslog. כן, RFC 5424 הישן והטוב. נולד בשנות ה-80, סטנדרטי ב-2009, וה"קאטטי קאתי" הבלתי מעורער של פרוטוקולי הודעות רשת. ראיתי רשתות בגודל צנוע מייצרות למעלה מ-4 מיליון הודעות סיסלוג בשעה. רוב זה היה מעשה חסר תועלת לחלוטין, שימו לב. אבל ההודעות האלה היו חייבות לעבור לאנשהו ולהיות מעובדות (או להפיל) על ידי מערכת כלשהי לאורך הדרך. זו אחת הסיבות שהצעתי "מערכת סינון" של syslog ומלכודת . מאז בעצם לנצח אם לא בורר על נפח ההודעות בצד, יש ערך בחלק מההודעות האלה, לחלק מהעוסקים בתחום ה-IT, חלק מהזמן. ולכן עלינו לשקול (ולאסוף) גם אותם. 1 2018-12-13T14:17:40.000Z myserver myapp 10 - [http_method="GET"; http_uri="/example"; http_version="1.1"; http_status="200"; client_addr="127.0.0.1"; http_user_agent="my.service/1.0.0"] HTTP request processed successfully כפי שהיא הודעת היומן היא 228 בתים - בקושי אפילו טיפה בדלי הטלמטריה שאתה אוסף בכל דקה, שלא לדבר על כל יום. אבל בשביל מה שאני עומד לעשות, אני רוצה השוואה אמיתית בין תפוחים לתפוחים, אז ככה זה ייראה אם הייתי מתקן את זה ב-JSON: { "pri": 134, "version": 1, "timestamp": "2018-12-13T14:17:40.000Z", "hostname": "myserver", "appname": "myapp", "procid": 10, "msgid": "-", "structuredData": { "http_method": "GET", "http_uri": "/example", "http_version": "1.1", "http_status": "200", "client_addr": "127.0.0.1", "http_user_agent": "my.service/1.0.0" }, "message": "HTTP request processed successfully" } זה מקפיץ את המטען עד ל-336 בתים ללא רווח לבן, או 415 בתים עם. כעת, לשם השוואה, הנה הודעת יומן OTLP לדוגמה: { "resource": { "service.name": "myapp", "service.instance.id": "10", "host.name": "myserver" }, "instrumentationLibrary": { "name": "myapp", "version": "1.0.0" }, "severityText": "INFO", "timestamp": "2018-12-13T14:17:40.000Z", "body": { "text": "HTTP request processed successfully" }, "attributes": { "http_method": "GET", "http_uri": "/example", "http_version": "1.1", "http_status": "200", "client_addr": "127.0.0.1", "http_user_agent": "my.service/1.0.0" } } ההודעה (הגנרית, המינימלית) הזו שוקלת 420 בתים (ללא רווח לבן; היא כוללת 520 בתים). זה עדיין קטנטן, אבל למרות זאת גרסת OTel עם רווח לבן גדולה ב-25% מההודעה המותאמת ב-JSON (עם רווח לבן), ויותר מפי שניים יותר מהודעת היומן המקורית. ברגע שנתחיל ליישם נתונים מהעולם האמיתי, הדברים מתבלים עוד יותר. הנקודה שלי כאן היא זו: אם OTel עושה את זה לכל הודעת יומן, העלויות הזעירות האלה מסתכמות במהירות. דוגמה 2: פרומתאוס מסתבר ששיטות מודרניות לניהול מדדים רגישות לא פחות לאינפלציה. מדד פרומתאוס טיפוסי, המעוצב ב-JSON, הוא 291 בתים. אבל אותו מדד שהומר לפורמט מדדי OTLP שוקל 751 בתים. זה נכון, ל-OTLP יש פונקציית אצווה שמפחיתה את זה, אבל זה עוזר רק בהעברה דרך החוט. ברגע שהוא מגיע ליעד, ספקים רבים (לא כולם, אבל רוב) מוציאים אצווה לפני האחסון, כך שהוא חוזר להיות גדול פי 2.5 מההודעה המקורית. כמו שחבר שלי ג'וש ביגלי אמר, "למדדי פי 2.5 לצרוך טוב יותר יש סיפור מדהים לספר על הקשר כדי להצדיק את העלות הזו." זה לא אתה, OTel, זה אנחנו. (אבל זה גם אתה) אם כל זה מרגיש קצת היפר-קריטי כלפי OTel, בבקשה תן לי הזדמנות להסביר. אני באמת מאמין ש-OTel הוא התקדמות מדהימה וכל מי שרציני בניטור וצפיות צריך לאמץ את זה כסטנדרט - זה מתאים למשתמשים וגם לספקים. היכולת לפלוט את הצמה של יומנים, מדדים, עקבות תוך שמירה על ההקשר שלה, ללא קשר ליעד, היא לא יסולא בפז. (אבל...) OTel תוכנן על ידי (ועבור) מהנדסי תוכנה. מקורו באותו עידן עברו (שאני מתכוון ל"2016") כאשר עדיין דאגנו יותר מהקושי להשיג את הנתונים מאשר עלות ההעברה, העיבוד והאחסון שלהם. OTel, בעיצובו, מוטה לנפח. למרות הבדיחה של כותרת המדור הזה, הבעיה היא באמת לא OTel. אנחנו באמת אשמים. במיוחד מערכת היחסים הלא בריאה שלנו עם טלמטריה. אם נתעקש לאסוף ולשדר כל נקודת מידע בודדת, אין לנו את מי להאשים מלבד עצמנו בחשבונות מרקיעי השמיים שאנו מקבלים בסוף החודש. האם הנתונים האלה מביאים לך שמחה? קל לתת לפתרון הנראות שלך לעשות את המשימות הכבדות ולהעביר כל בייט של נתונים לממשק מאוחד. זה קל לעשות אם אתה מהנדס תוכנה שבבעלותם (לפחות נומינלית) את פתרונות הניטור והצפייה. זה אפילו יותר קל אם אתה רק צרכן של השירותים האלה, צופה תמים מהצד. אנשים שנכללים בקטגוריה זו כוללים את אלה הקשורים באופן הדוק לממגורה מסוימת (בסיס נתונים, אחסון, רשת וכו'); או צוותי מוקד ו-NOC שמקבלים את הכרטיסים ומספקים תמיכה אך אינם מעורבים במכשור או בכלים שאליהם מחובר המכשור; או צוותים עם צרכים מיוחדים יותר שבכל זאת חופפים לניטור וצפייה, כמו אבטחת מידע. אבל בוא נהיה כנים, אם אתה מהנדס אבטחה, איך אתה יכול להצדיק תשלום כפול עלות להטמעת יומנים או מדדים, לעומת הסטנדרטים הטובים לחלוטין שכבר קיימים וששירו היטב במשך שנים? האם זה אומר שאולי אתה משתמש ביותר מכלי אחד? כֵּן. אבל כפי שציינתי ( אחר ) אין (ואף פעם לא היה ולא יהיה) פתרון חד-משמעי שמתאים לכולם. וברוב המצבים אין אפילו פתרון אחד שמתאים ל-MOST. ניטור וצפייה תמיד היו על יישומים הטרוגניים. ככל שתקדים לאמץ את האידיאל הזה, כך תתחיל לבנות מוקדם יותר מערכות אקולוגיות של צפיות המשרתות את הצרכים שלך, הצוות שלך והעסק שלך. פעם פעם ופעם ועוד פעם ועוד פעם לשם כך יש לקיים דיון רציני על החזר ROI לפני שתכנסו ל-OTel או לכל פתרון צפייה. (בינתיים) ראינו בעבר מעבר מתמחור לפי מושב (או ממשק, או שלדה או מעבד) למודל צריכה בשוק. וראינו גם טכנולוגיות זזות אחורה (כמו האופן שבו השירות הסלולרי עבר מדקה או לכל טקסט לנתונים בלתי מוגבלים בתשלום לחודש). אני חושד שאולי נראה מטוטלת דומה מתנדנדת לאחור עם ניטור וצפייה בזמן כלשהו בעתיד. אבל לעת עתה, עלינו להתמודד עם שיטת התמחור הרווחת כפי שהיא קיימת כיום; ובכפייתיות שלנו - שנולדה בנקודה אחרת בהיסטוריה של הניטור - לאסוף, לשדר ולאחסן כל פיסת (ובייט) של טלמטריה שעוברת מתחת לאף שלנו. כמובן שהעלות היא לא הגורם היחיד. יש לקחת בחשבון ביצועים, סיכונים (ועוד). אבל בלב הכל עומד הצורך האמיתי שלנו להתחיל לשאול את עצמנו: מה אעשה עם הנתונים האלה? מי ישתמש בו? כמה זמן אני צריך לאחסן אותו? וכמובן, מי לעזאזל ישלם על זה?