rrdcreate - מקוון בענן

תָכְנִית:

שֵׁם

rrdcreate - הגדר מסד נתונים חדש של Round Robin

תַקצִיר

rrdtool לִיצוֹר שם הקובץ [--הַתחָלָה|-b שעת התחלה] [--שלב|-s צעד] [--תבנית|-t תבנית-
פילה] [--מָקוֹר|-r קובץ מקור] [--אין להחליף|-O] [--דימון|-d כתובת] [DS:ds-
שם[=mapd-ds-name[[מקור-אינדקס]]]:STD:טיעוני dst] [RRA:CF:ראה טיעונים]

תיאור

פונקציית היצירה של RRDtool מאפשרת לך להגדיר מסד נתונים חדש של Round Robin (DRR) קבצים. ה
הקובץ נוצר בגודלו הסופי, המלא ומלא ב *לא ידוע* נתונים, אלא אם כן אחד או יותר
מָקוֹר DRR הקבצים צוינו והם מכילים נתונים מתאימים כדי "למלא מראש" את החדש DRR
קובץ.

שם הקובץ
השם של DRR שאתה רוצה ליצור. DRR הקבצים צריכים להסתיים עם הסיומת .rrd.
עם זאת, כלי RRD יקבל כל שם קובץ.

--התחל|-ב התחלה זמן (בְּרִירַת מֶחדָל: עַכשָׁיו - 10 שניות)
מציין את הזמן בשניות מאז 1970-01-01 UTC שבו יש להוסיף את הערך הראשון ל
מה היא DRR. כלי RRD לא יקבל נתונים כלשהם שנקבעו לפני או בזמן שצוין.

ראה גם סעיף מפרט זמן AT-STYLE ב- rrdfetch תיעוד לדרכים אחרות
כדי לציין זמן.

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

--שלב|-s צעד (בְּרִירַת מֶחדָל: 300 שניות)
מציין את מרווח הבסיס בשניות שבו הנתונים יוזנו לתוך DRR.
גורם קנה מידה עשוי להיות קיים כסיומת למספר השלם; ראה "צעד, פעימות לב ושורות
בתור משכי זמן".

--אין-דרוס|-O
אל תחסום קובץ קיים באותו שם.

--דימון|-ד כתובת
כתובת של הדמון rrdcached. לרשימה של פורמטים מקובלים, עיין ב- -l אפשרות ב
מדריך rrdcached.

rrdtool create --daemon unix:/var/run/rrdcached.sock /var/lib/rrd/foo.rrd I

[--תבנית|-ט תבנית-קובץ]
מציין תבנית DRR קובץ לקחת צעד, הגדרות DS ו-RRA. זה מאפשר אחד
לבסס את המבנה של קובץ חדש על קובץ קיים כלשהו. הנתונים של קובץ התבנית
אינו משמש למילוי מוקדם, אך ניתן לציין את אותו קובץ כקובץ מקור
(ראה למטה).

הגדרות נוספות של DS ו-RRA מותרות, ויתווספו לאלו שנלקחו מה-
תבנית.

--מקור|-r קובץ מקור
מקור אחד או יותר DRR קבצים עשויים לקבל שם בשורת הפקודה. נתונים ממקור אלה
קבצים ישמשו למילוי מראש של הקובץ שנוצר DRR קוֹבֶץ. קובץ הפלט וקובץ מקור אחד
עשוי להתייחס לאותו שם קובץ. זה למעשה יחליף את קובץ המקור ב-
חדש DRR קוֹבֶץ. אמנם יש סכנה לאבד את קובץ המקור בגלל שהוא מוחלף,
אין סכנה שהמקור והקובץ החדש יהיו "משובשים" ביחד בכל נקודה
בזמן, כי הקובץ החדש תמיד יווצר כקובץ זמני תחילה ויעשה
יועבר ליעדו הסופי רק לאחר שנכתב בשלמותו.

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

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

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

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

מילוי מוקדם פועל כעת באופן אמין רק עבור RRAs באמצעות אחד מהאיחוד הקלאסי
פונקציות, כלומר אחת מ: AVERAGE, MIN, MAX, LAST. ייתכן גם שיש לו בעיות כרגע
עם מקורות נתונים של COMPUTE.

שימו לב כי פעולת המילוי המוקדמת במהלך לִיצוֹר דומה להרבה מהפעולות
זמין באמצעות מנגינה פקודה, אבל באמצעות לִיצוֹר תחביר.

DS:ds-name[=mapd-ds-name[[מקור-אינדקס]]]:STD:dst טיעונים
אחת DRR יכול לקבל קלט ממספר מקורות נתונים (DS), למשל נכנסות ו
תעבורה יוצאת בקו תקשורת ספציפי. עם ה DS אפשרות תצורה אתה
חייב להגדיר כמה מאפיינים בסיסיים של כל מקור נתונים שברצונך לאחסן ב- DRR.

ds-name הוא השם שבו תשתמש כדי להפנות למקור הנתונים הספציפי הזה מ-an DRR.
ds-name חייב להיות באורך של 1 עד 19 תווים בתווים [a-zA-Z0-9_].

STD מגדיר את סוג מקור הנתונים. שאר הארגומנטים של הזנת מקור נתונים תלויים ב
סוג מקור הנתונים. עבור GAUGE, COUNTER, DERIVE, DCOUNTER, DDERIVE ו-ABSOLUTE את
הפורמט עבור ערך מקור נתונים הוא:

DS:ds-name:{מַד | COUNTER | לְהָפִיק | DCOUNTER | DDERIVE | מוּחלָט}:דופק לב:דקות:מקסימום

עבור מקורות נתונים COMPUTE, הפורמט הוא:

DS:ds-name:לְחַשֵׁב:ביטוי rpn

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

מַד
מיועד לדברים כמו טמפרטורות או מספר אנשים בחדר או הערך של RedHat
.

COUNTER
מיועד להגדלה מתמשכת של מונים כמו מונה ifInOctets בנתב. ה
COUNTER מקור הנתונים מניח שהמונה לעולם אינו פוחת, למעט כאשר מונה
עולה על גדותיו. פונקציית העדכון לוקחת בחשבון את ההצפה. הדלפק הוא
מאוחסן כשיעור לשנייה. כאשר המונה עולה על גדותיו, RRDtool בודק אם
הצפה התרחשה בגבול 32bit או 64bit ופועלת בהתאם על ידי הוספת an
ערך מתאים לתוצאה.

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

לְהָפִיק
יאחסן את הנגזרת של השורה העוברת מהערך האחרון לערך הנוכחי של
מקור מידע. זה יכול להיות שימושי עבור מדידים, למשל, למדידת שיעור האנשים
כניסה או יציאה מחדר. באופן פנימי, ה-Dirive עובד בדיוק כמו COUNTER אבל בלי
המחאות הצפה. אז אם המונה שלך לא מתאפס על 32 או 64 ביט, אולי תרצה
השתמש ב-DERIVE ושלב אותו עם ערך MIN של 0.

DDERIVE
אותו הדבר כמו לְהָפִיק, אבל עבור כמויות המבוטאות כנקודה צפה בעלת דיוק כפול
מספר.

הערה on COUNTER vs לְהָפִיק

מאת דון ברדה[מוגן בדוא"ל]>

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

עבור צעד של 5 דקות ומונה של 32 סיביות, ההסתברות לטעות באיפוס מונה
עבור גלישה לגיטימית היא ללא ספק כ-0.8% לכל 1Mbps של רוחב פס מקסימלי. ציין זאת
זה שווה ל-80% עבור ממשקי 100Mbps, אז עבור ממשקי רוחב פס גבוה ו-
מונה 32bit, DERIVE עם min=0 כנראה עדיף. אם אתה משתמש ב-64bit
מונה, כמעט כל הגדרה מקסימלית תבטל את האפשרות לטעות ב-a
לאפס עבור גלישת נגד.

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

לְחַשֵׁב
מיועד לאחסון התוצאה של נוסחה המיושמת על מקורות נתונים אחרים ב- DRR. זֶה
מקור הנתונים אינו מסופק ערך בעדכון, אלא נקודות הנתונים העיקריות שלו
(PDPs) מחושבים מה-PDP של מקורות הנתונים לפי ביטוי rpn
שמגדיר את הנוסחה. פונקציות איחוד מיושמות לאחר מכן כרגיל על
PDPs של מקור הנתונים COMPUTE (כלומר ביטוי rpn מוחל רק על
ליצור PDPs). בתוכנת מסד נתונים, מערכי נתונים כאלה מכונים "וירטואליים" או
עמודות "מחושבות".

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

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

If מידע on מינימלי/מקסימלי צפוי ערכים is זמין, תמיד סט מה היא דקות ו / או
מקסימום נכסים. זֶה יצטרך לעזור כלי RRD in עושה a פשוט שְׁפִיוּת לבדוק on מה היא נתונים שסופק
מתי ריצה לעדכן.

ביטוי rpn מגדיר את הנוסחה המשמשת לחישוב ה-PDP של מקור נתונים COMPUTE
מקורות נתונים אחרים באותו . זה דומה להגדרת א CDEF טיעון עבור
פקודת גרף. אנא עיין בדף המדריך לרשימה ותיאור של RPN
פעולות נתמכות. עבור מקורות נתונים COMPUTE, פעולות ה-RPN הבאות אינן
נתמכים: COUNT, PREV, TIME ו-LTIME. בנוסף, בהגדרת ביטוי RPN, ה
מקור הנתונים COMPUTE עשוי להתייחס רק לשמות של מקור הנתונים המפורטים קודם לכן ב
צור פקודה. זה דומה להגבלה ש CDEFs חייב להתייחס רק DEFים ו
CDEFs שהוגדרו בעבר באותה פקודת גרף.

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

למשל, ה-DS

DS:a=b[2]:GAUGE:120:0:U

מציין ששם ה-DS a יש למלא מראש מה-DS הנקרא b בשנייה
קובץ המקור הרשום (מדדי המקור מבוססים על 1).

RRA:CF:cf טיעונים
המטרה של DRR הוא לאחסן נתונים בארכיונים של round robin (RRA). ארכיון
מורכב ממספר ערכי נתונים או נתונים סטטיסטיים עבור כל אחד ממקורות הנתונים המוגדרים
(DS) ומוגדר עם an RRA קו.

כאשר נתונים מוזנים לתוך DRR, הוא מותאם תחילה למשבצות זמן באורך שהוגדר
עם -s אפשרות, ובכך הופך ל-a יְסוֹדִי נתונים נקודה.

הנתונים מעובדים גם עם פונקציית הקונסולידציה (CF) של הארכיון. יש
מספר פונקציות איחוד המאחדות נקודות נתונים ראשיות באמצעות מצרף
פוּנקצִיָה: מְמוּצָע, MIN, מקס, אחרון.

מְמוּצָע
הממוצע של נקודות הנתונים נשמר.

MIN הקטנה ביותר מבין נקודות הנתונים מאוחסנת.

MAX מאוחסנת הגדולה מבין נקודות הנתונים.

אחרון
נעשה שימוש בנקודות הנתונים האחרונות.

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

הפורמט של RRA הקו עבור פונקציות איחוד אלו הוא:

RRA:{מְמוּצָע | MIN | מקס | אחרון}:xff:צעדים:שורות

xff גורם xfiles מגדיר מאיזה חלק מרווח איחוד עשוי להיות מורכב
*לא ידוע* נתונים בעוד שהערך המאוחד עדיין נחשב כידוע. זה ניתן בתור
יחס של מותר *לא ידוע* PDPs למספר PDPs במרווח. לפיכך, זה טווח
מ-0 ל-1 (בלעדי).

צעדים מגדיר כמה כאלה יְסוֹדִי נתונים נקודות משמשים לבניית א המאוחדים נתונים
נקודה שלאחר מכן נכנס לארכיון. ראה גם "STEP, HEARTBEAT, ו-Rows As
משכי זמן".

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

סוטה התנהגות איתור עם הולט-חורף חזוי

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

· RRA:HWPREDICT:שורות:אלפא:בטא:עונתי תקופה[:rra-num]

· RRA:MHWPREDICT:שורות:אלפא:בטא:עונתי תקופה[:rra-num]

· RRA:עוֹנָתִי:עונתי תקופה:גמא:rra-num[:החלקה-חלון=שבריר]

· RRA:DEVSEASONAL:עונתי תקופה:גמא:rra-num[:החלקה-חלון=שבריר]

· RRA:DEVPREDICT:שורות:rra-num

· RRA:כישלונות:שורות:סף:חלון אורך:rra-num

אלה RRAs שונים מפונקציות האיחוד האמיתיות בכמה דרכים. ראשית, כל אחד
מה היא RRAs מתעדכן פעם אחת עבור כל נקודת נתונים ראשית. שנית, אלה RRAs יש לו
תלות הדדית. כדי ליצור גבולות ביטחון בזמן אמת, סט מותאם של SEASONAL,
DEVSEASONAL, DEVPREDICT ו-HWPREDICT או MHWPREDICT חייבים להתקיים. יוצר
ערכים מוחלקים של נקודות הנתונים העיקריות מחייבים עונתיות RRA או HWPREDICT
או MHWPREDICT RRA. זיהוי התנהגות חריגה מחייב FAILURES, DEVSEASONAL, SEASONAL,
או HWPREDICT או MHWPREDICT.

הערכים החזויים, או המוחלקים, מאוחסנים ב-HWPREDICT או MHWPREDICT RRA.
HWPREDICT ו-MHWPREDICT הן למעשה שתי וריאציות על שיטת Holt-Winters. הם
ניתן להחלפה. שניהם מנסים לפרק נתונים לשלושה מרכיבים: קו בסיס, א
מגמה, ומקדם עונתי. HWPREDICT מוסיף את המקדם העונתי שלו ל-
קו הבסיס ליצירת חיזוי, בעוד ש-MHWPREDICT מכפיל את המקדם העונתי שלו ב-
קו הבסיס ליצירת תחזית. ההבדל מורגש כאשר קו הבסיס משתנה
באופן משמעותי במהלך עונה; HWPREDICT חוזה שהעונתיות תישאר
קבוע כאשר קו הבסיס משתנה, אך MHWPREDICT חוזה את העונתיות שתגדל או
להתכווץ ביחס לקו הבסיס. הבחירה הנכונה של השיטה תלויה בדבר
מדגם. למען הפשטות, שאר הדיון הזה יתייחס ל-HWPREDICT, אבל
ניתן להחליף את MHWPREDICT במקומו.

הסטיות החזויות מאוחסנות ב-DEVPREDICT (תחשוב על סטיית תקן שיכולה להיות
קנה מידה כדי להניב רצועת ביטחון). הכשלים RRA מאחסן אינדיקטורים בינאריים. א 1 סימן
ההתבוננות הצמודה ככישלון; כלומר, מספר האמון מגביל את ההפרות
חלון התצפיות הקודם עמד בסף מוגדר או עבר אותו. דוגמה של
באמצעות אלה RRAs לצייר גרף של גבולות אמון וכישלונות מופיע ב-rrdgraph.

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

על מנת לפשט את היצירה עבור המשתמש המתחיל, בנוסף לתמיכה במפורש
יצירת ה-HWPREDICT, SEASONAL, DEVPREDICT, DEVSEASONAL ו-FAILURES RRAs, ה
כלי RRD הפקודה create תומכת ביצירה מרומזת של ארבעת האחרים כאשר HWPREDICT הוא
פירוט לבד והטיעון האחרון rra-num מושמט.

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

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

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

בטא הוא פרמטר ההסתגלות של מקדם השיפוע (או המגמה הליניארית) ב- Holt-
אלגוריתם חיזוי חורף. בטא חייב להיות בין 0 ל-1 וממלא את אותו תפקיד כמו
אלפא ביחס למגמה הליניארית החזויה.

גמא הוא פרמטר ההסתגלות של המקדמים העונתיים בהולט-חורף
אלגוריתם חיזוי (HWPREDICT) או פרמטר ההתאמה בהחלקה המעריכית
עדכון של הסטיות העונתיות. הוא חייב להיות בין 0 ל-1. אם ה-SEASONAL ו
DEVSEASONAL RRAs נוצרים באופן מרומז, לשניהם יהיה אותו ערך עבור גמא: ה
הערך שצוין עבור ה-HWPREDICT אלפא טַעֲנָה. שימו לב כי יש אחד עונתי
מקדם (או סטייה) עבור כל נקודת זמן במהלך המחזור העונתי, ההתאמה
הקצב איטי בהרבה מקו הבסיס. כל מקדם עונתי מתעדכן רק (או
מסתגל) כאשר הערך הנצפה מתרחש בהיסט במחזור העונתי המקביל
למקדם הזה.

אם עונתית ו-DEVSEASONAL RRAs נוצרו במפורש, גמא לא צריך להיות זהה עבור
שניהם. ציין זאת גמא ניתן לשנות גם דרך כלי RRD מנגינה פקודה.

החלקה-חלון מציין את החלק של העונה שיש לממוצע סביב כל אחת מהן
נְקוּדָה. כברירת מחדל, הערך של החלקה-חלון הוא 0.05, כלומר כל ערך ב
SEASONAL ו-DEVSEASONAL יוחלפו מדי פעם בממוצע שלהם עם (עונתי
תקופה*0.05) השכנים הקרובים ביותר. הגדרה החלקה-חלון לאפס ישבית את
באופן ממוצע חלק יותר לגמרי.

rra-num מספק את הקישורים בין קשורים RRAs. אם HWPREDICT מצוין לבד וה-
אַחֵר RRAs נוצרים באופן מרומז, אז אין צורך לדאוג לגבי הטיעון הזה. אם
RRAs נוצרו במפורש, אז שימו לב היטב לטיעון זה. לכל אחד RRA
הכולל את הטיעון הזה, יש תלות בין זה RRA ועוד אחת RRA. ה
rra-num ארגומנט הוא האינדקס המבוסס על 1 בסדר של RRA יצירה (כלומר, הסדר
הם מופיעים ב לִיצוֹר פקודה). התלויים RRA לכל אחד RRA הדורש את rra-num
הטיעון מופיע כאן:

· HWPREDICT rra-num הוא המדד של ה-SEASONAL RRA.

· עונתי rra-num הוא האינדקס של ה-HWPREDICT RRA.

· DEVPREDICT rra-num הוא המדד של DEVSEASONAL RRA.

· DEVSEASONAL rra-num הוא האינדקס של ה-HWPREDICT RRA.

· כשלים rra-num הוא המדד של DEVSEASONAL RRA.

סף הוא המספר המינימלי של הפרות (ערכים שנצפו מחוץ לביטחון
bounds) בתוך חלון המהווה כישלון. אם הכשלים RRA הוא במשתמע
נוצר, ערך ברירת המחדל הוא 7.

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

שלב, דופק לב, ו שורות As משכי זמן

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

rrdtool ליצור power.rrd \
--התחל עכשיו-2 שעות --שלב 1 \
DS:watts:GAUGE:300:0:24000 \
RRA:AVERAGE:0.5:1:864000 \
RRA:AVERAGE:0.5:60:129600 \
RRA:AVERAGE:0.5:3600:13392 \
RRA:AverAGE:0.5:86400:3660

יוצר מסד נתונים של ערכי הספק שנאספים פעם בשנייה, עם חמש דקות (300
שני) פעימות לב וארבע RRAs: עשרה ימים של שנייה אחת, 90 ימים של דקה אחת, 18 חודשים
של שעה אחת, ועשר שנים של ממוצעים של יום אחד.

ניתן לציין גם ספירות ושורות צעדים, פעימות לב ו-PDP כמשכים, שהם
מספרים שלמים חיוביים עם סיומת של תו בודד המציינת גורם קנה מידה. לִרְאוֹת
"rrd_scaled_duration" ב-librrd עבור גורמי קנה מידה של הסיומות הנתמכות: "s"
(שניות), "m" (דקות), "h" (שעות), "d" (ימים), "w" (שבועות), "M" (חודשים) ו-"y"
(שנים).

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

עם תכונה זו ניתן לכתוב את אותו מפרט כמו לעיל כך:

rrdtool ליצור power.rrd \
--התחל עכשיו-2 שעות --שלב 1s \
DS:watts:GAUGE:5m:0:24000 \
RRA:AVERAGE:0.5:1s:10d \
RRA:AVERAGE:0.5:1m:90d \
RRA:AVERAGE:0.5:1h:18M \
RRA:AverAGE:0.5:1d:10y

השמיים דופק לב ו מה היא שלב

הנה הסבר מאת דון ברדה על פעולתו הפנימית של RRDtool. זה עשוי לעזור לך
לברר מדוע כל הנתונים *לא ידועים* האלה צצים במסדי הנתונים שלך:

RRDtool מקבל דגימות/עדכונים מוזנים בזמנים שרירותיים. מתוך אלה הוא בונה נתונים ראשיים
נקודות (PDPs) בכל מרווח "צעד". לאחר מכן ה-PDPs מצטברים לתוך ה-RRAs.

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

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

"פעימת הלב" יכולה להיות קצרה (יוצאת דופן) או ארוכה (אופיינית) ביחס למרווח ה"צעד"
בין PDPs. "פעימת לב" קצרה פירושה שאתה דורש מספר דגימות לכל PDP, ואם אתה
אל תשיג אותם לסמן את ה-PDP לא ידוע. דופק ארוך יכול להשתרע על מספר "צעדים", אשר
פירושו שמקובל לחשב מספר PDPs ממדגם בודד. קיצוני
דוגמה לכך עשויה להיות "צעד" של 5 דקות ו"דופק" של יום אחד, ובמקרה כזה
דגימה בודדת בכל יום תגרום לכך שכל ה-PDP עבור כל תקופת היום יוגדרו
לאותו שיעור ממוצע. -- דון בארדה <[מוגן בדוא"ל]>

זמן|
ציר|
להתחיל__|00|
| 01 |
u|02|----* sample1, הפעל מחדש את "hb"-טיימר
u|03| /
u|04| /
u|05| /
u|06|/ "hbt" פג
u|07|
|08|----* sample2, הפעל מחדש את "hb"
|09| /
|10| /
u|11|----* sample3, הפעל מחדש את "hb"
u|12| /
u|13| /
step1_u|14| /
u|15|/ "swt" פג
u|16|
|17|----* sample4, הפעל מחדש את "hb", צור "pdp" עבור step1 =
|18| / = לא ידוע עקב 10 שניות עם התווית "u" > 0.5 * צעד
|19| /
|20| /
|21|----* sample5, הפעל מחדש את "hb"
|22| /
|23| /
|24|----* sample6, הפעל מחדש את "hb"
|25| /
|26| /
|27|----* sample7, הפעל מחדש את "hb"
step2__|28| /
|22| /
|23|----* sample8, הפעל מחדש את "hb", צור "pdp" עבור שלב 1, צור "cdp"
|24| /
|25| /

גרפיקה מאת [מוגן בדוא"ל].

איך ל מידה

הנה כמה עצות כיצד למדוד:

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

הודעות דואר
נניח שיש לך שיטה לספור את מספר ההודעות המועברות בדואר שלך
שרת בפרק זמן מסוים, נותן לך נתונים כמו '5 הודעות ב-65 האחרונות
שניות'. אם אתה מסתכל על הספירה של 5 כמו an מוּחלָט סוג נתונים אתה יכול פשוט
עדכן את ה-RRD עם המספר 5 וזמן הסיום של תקופת הניטור שלך. כלי RRD
לאחר מכן יתעד את מספר ההודעות בשנייה. אם בשלב מאוחר יותר תרצה
לדעת את מספר ההודעות המועברות ביום, אתה יכול לקבל את ממוצע ההודעות לכל
שנייה מ-RRDtool עבור היום המדובר והכפילו את המספר הזה עם המספר
של שניות ביום. מכיוון שכל המתמטיקה מתנהלת עם Doubles, הדיוק צריך להיות
קָבִיל.

זה תמיד תעריף
RRDtool מאחסן תעריפים בכמות/שנייה עבור COUNTER, DERIVE, DCOUNTER, DDERIVE ו
נתונים אבסולוטיים. כאשר אתה מתווה את הנתונים, תקבל על ציר y כמות/שנייה אשר
אתה עלול להתפתות להמיר לסכום מוחלט על ידי הכפלה בזמן הדלתא
בין הנקודות. RRDtool משרטט נתונים רציפים, וככזה אינו מתאים עבור
שרטוט כמויות מוחלטות כמו למשל "סך הכל בתים" שנשלחו והתקבלו בנתב.
מה שאתה כנראה רוצה זה קצבי עלילה שאתה יכול לשנות לבייטים/שעה, למשל, או
מתווים כמויות מוחלטות עם כלי אחר שמצייר עלילות-בר, היכן שהזמן-דלתא נמצא
ברור על העלילה עבור כל נקודה (כגון שכאשר אתה קורא את הגרף אתה רואה עבורו
דוגמה GB על ציר y, ימים על ציר x ופס אחד לכל יום).

דוגמא

rrdtool create temperature.rrd --שלב 300 \
DS:temp:GAUGE:600:-273:5000 \
RRA:AVERAGE:0.5:1:1200 \
RRA:MIN:0.5:12:2400 \
RRA:MAX:0.5:12:2400 ​​\
RRA:AverAGE:0.5:12:2400

זה מגדיר א DRR נקרא temperature.rrd שמקבל ערך טמפרטורה אחד כל 300
שניות. אם לא מסופקים נתונים חדשים במשך יותר מ-600 שניות, הטמפרטורה הופכת
*לא ידוע*. הערך המינימלי המקובל הוא -273 והמקסימום הוא 5.

כמו כן מוגדרים כמה אזורי ארכיון. הראשון מאחסן את הטמפרטורות שסופקו עבור 100
שעות (1'200 * 300 שניות = 100 שעות). ה-RRA השני מאחסן את הטמפרטורה המינימלית
נרשם על פני כל שעה (12 * 300 שניות = שעה), במשך 1 ימים (100'2 שעות). ה
ה-RRA השלישי והרביעי עושים את אותו הדבר עבור הטמפרטורה המקסימלית והממוצעת,
בהתאמה.

דוגמא 2

rrdtool create monitor.rrd --שלב 300 \
DS:ifOutOctets:COUNTER:1800:0:4294967295 \
RRA:AVERAGE:0.5:1:2016 \
RRA:HWPREDICT:1440:0.1:0.0035:288

דוגמה זו היא צג של ממשק נתב. הראשון RRA עוקב אחר זרימת התנועה פנימה
אוקטטים; השני RRA מייצר את הפונקציות המיוחדות RRAs על התנהגות חריגה
איתור. שימו לב שה- rra-num הטיעון של HWPREDICT חסר, אז השני RRAs יצטרך
נוצר באופן מרומז עם ערכי ברירת מחדל של פרמטרים. בדוגמה זו, החיזוי
קו הבסיס של האלגוריתם מסתגל במהירות; למעשה השעה האחרונה של תצפיות (כל אחת
במרווחים של 5 דקות) מהווה 75% מהתחזית הבסיסית. המגמה הליניארית
התחזית מסתגלת הרבה יותר לאט. תצפיות שנעשו במהלך היום האחרון (ב-288
תצפיות ליום) מהוות רק 65% מהמגמה הליניארית החזויה. הערה: אלה
חישובים מסתמכים על נוסחת החלקה אקספוננציאלית המתוארת במאמר LISA 2000.

המחזור העונתי הוא יום אחד (288 נקודות נתונים במרווחים של 300 שניות), והמחזור העונתי
פרמטר ההתאמה יוגדר ל-0.1. קובץ RRD יאחסן 5 ימים (1 נקודות נתונים)
של תחזיות ותחזיות חריגות לפני לעטוף. הקובץ יאוחסן יום אחד (א
מחזור עונתי) של 0-1 אינדיקטורים ב-FAILURES RRA.

אותו קובץ RRD ו RRAs נוצרים עם הפקודה הבאה, אשר במפורש
יוצר את כל הפונקציות המיוחדות RRAs באמצעות "צעד, פעימות לב ושורות כמשכי זמן".

rrdtool create monitor.rrd --שלב 5m \
DS:ifOutOctets:COUNTER:30m:0:4294967295 \
RRA:AVERAGE:0.5:1:2016 \
RRA:HWPREDICT:5d:0.1:0.0035:1d:3 \
RRA:SEASONAL:1d:0.1:2 \
RRA:DEVSEASONAL:1d:0.1:2 \
RRA:DEVPREDICT:5d:5 \
RRA:FAILURES:1d:7:9:5

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

דוגמא 3

rrdtool create proxy.rrd --שלב 300 \
DS:Requests:DERIVE:1800:0:U \
DS:Duration:DERIVE:1800:0:U \
DS:AvgReqDur:COMPUTE:Duration,Requests,0,EQ,1,Requests,IF,/\
RRA:AverAGE:0.5:1:2016

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

ב DRR, מקור הנתונים הראשון מאחסן את קצב הבקשות לשנייה במהלך המרווח.
מקור הנתונים השני מאחסן את משך הזמן הכולל של כל הבקשות שעובדו במהלך
מרווח חלקי 300. מקור הנתונים COMPUTE מחלק כל PDP של AccuDuration ב-
ה-PDP המקביל של TotalRequests ומאחסן את משך הבקשה הממוצע. ה
שאר ביטוי ה-RPN מטפל בחלוקה באפס.

מחברים

טוביאס אוטיקר[מוגן בדוא"ל]>, פיטר סטמפסט[מוגן בדוא"ל]>

השתמש ב-rrdcreate באינטרנט באמצעות שירותי onworks.net