คำถามติดแท็ก graphite

เท่าที่ฉันสามารถบอกได้นี่คือความแตกต่างที่สำคัญ: OpenTSDBไม่ทำให้ข้อมูลเสื่อมสภาพเมื่อเวลาผ่านไปซึ่งแตกต่างจากGraphiteที่ขนาดของฐานข้อมูลถูกกำหนดไว้ล่วงหน้า OpenTSDB สามารถจัดเก็บการวัดต่อวินาทีเมื่อเทียบกับ Graphite ซึ่งมีช่วงเวลาเป็นนาที (ฉันไม่แน่ใจในเรื่องนี้เอกสาร Graphite แสดงนโยบายการเก็บข้อมูลที่เก็บการวัดทุกนาที แต่ฉันไม่รู้ว่านี่เป็นหน่วยต่ำสุดของเวลาหรือไม่ สามารถเล่นด้วย) ฉันต้องการตัดสินใจอย่างชาญฉลาดเกี่ยวกับเครื่องมือที่จะใช้ในการจัดเก็บตัวชี้วัดฉันเคยพลาดความแตกต่างอื่น ๆ ในทั้งสองระบบหรือไม่ พวกเขาเป็นนักแสดง / ปรับขนาดได้อย่างไร? คำถามโบนัส: มีระบบอนุกรมเวลาอื่นใดที่ฉันควรดู?

28 monitoring  metrics  graphite  opentsdb 

ฉันต้องการตั้งค่า statsd / graphite เพื่อให้ฉันสามารถบันทึกแอปพลิเคชัน JS ที่ทำงานบนอุปกรณ์ HTML (เช่นไม่ได้อยู่ในสภาพแวดล้อม LAN ที่มีอยู่และอาจมีข้อมูลขาเข้าจำนวนมากที่ฉันไม่ได้ควบคุมโดยตรง) ข้อ จำกัด ของฉัน: จุดเข้าใช้งานต้องพูด HTTP: สิ่งนี้ได้รับการแก้ไขโดยพร็อกซี HTTP-to-UDP-statsd อย่างง่าย (เช่น. httpstatsd บน github) ต้องต่อต้านความล้มเหลวของเซิร์ฟเวอร์เดียว (เพื่อต่อสู้กับกฎของ Murphy :) จะต้องปรับขนาดได้ในแนวนอน: webscale, baby! :) สถาปัตยกรรมควรถูกเก็บไว้อย่างเรียบง่าย (และถูก) ที่สุด เซิร์ฟเวอร์ของฉันเป็นเครื่องเสมือน ไฟล์ข้อมูลจะถูกเก็บไว้ในเครื่อง filer (ด้วย NFS) ฉันมีตัวปรับสมดุลโหลดฮาร์ดแวร์ tcp / udp เมื่อทำการกำจัด ในระยะสั้นเส้นทางข้อมูล: [ลูกค้า] - (http) -> [http2statsd] …

17 http  high-availability  scalability  graphite  statsd 

ฉันพยายามที่จะตั้งค่าไฟท์บน Mac OS X 10.7 lion ฉันได้ตั้ง apache เพื่อเรียกสคริปต์ python graphite ผ่าน WSGI แต่เมื่อฉันพยายามเข้าถึงมันฉันจะได้รับการห้ามจาก apache และในบันทึกข้อผิดพลาด . "client denied by server configuration: /opt/graphite/webapp/graphite.wsgi" ฉันได้ตรวจสอบแล้วว่าตำแหน่งสคริปต์ได้รับอนุญาตใน httpd.conf และการอนุญาตของไฟล์ แต่ดูเหมือนว่าถูกต้อง ฉันต้องทำอะไรเพื่อเข้าถึง ด้านล่างคือ httpd.conf ซึ่งเกือบจะเป็นตัวอย่างของกราไฟท์ <IfModule !wsgi_module.c> LoadModule wsgi_module modules/mod_wsgi.so </IfModule> WSGISocketPrefix /usr/local/apache/run/wigs <VirtualHost _default_:*> ServerName graphite DocumentRoot "/opt/graphite/webapp" ErrorLog /opt/graphite/storage/log/webapp/error.log CustomLog /opt/graphite/storage/log/webapp/access.log common …

16 apache-2.2  wsgi  graphite 

ไม่มีใครมีสูตรใด ๆ หรืออาจมีข้อมูลตัวอย่างบางส่วนจากสภาพแวดล้อมของพวกเขาที่สามารถช่วยฉันประเมินว่าจะใช้เนื้อที่ดิสก์โดยแกรไฟต์ต่อดาต้าพอยน์เท่าใด

14 monitoring  graphite 

ฉันมีเคาน์เตอร์ที่และต้องการที่จะย้ายไปยังstats.message.foostats.messages.foo ฉันได้อัปเดตรหัสของฉันเพื่อเติมตัวนับใหม่ แต่ตัวเก่ายังคงอยู่ ฉันได้อ่านทั้งหมดที่ฉันต้องทำเพื่อลบสถิติจากกราไฟต์คือการลบไฟล์เสียงกระซิบที่เหมาะสมบนดิสก์อย่างไรก็ตามดูเหมือนว่าภายในไม่กี่วินาทีของการลบwspมันจะได้รับการสร้างใหม่ (ไม่มีข้อมูล) นี้เป็นความน่ารำคาญถ้าผมต้องการที่จะเปลี่ยนชื่อคีย์ที่ข้อมูลจะถูกเก็บไว้ภายใต้เท่าที่ผมต้องจำไว้ที่สำคัญคือการที่ถูกต้อง ไม่มีใครรู้วิธีลบเคาน์เตอร์เก่าอย่างถาวรหรือไม่

14 graphite  statsd 

ฉันใช้ชุดทดสอบโหลดเพื่อตรวจสอบประสิทธิภาพของการตั้งค่าต่อไปนี้: Node.js test suite (client) --> StatsD (server) --> Graphite (server) กล่าวโดยย่อชุดทดสอบ node.js จะส่งจำนวนเมตริกที่กำหนดทุก ๆ วินาทีไปยังอินสแตนซ์ StatsD ซึ่งอยู่บนเซิร์ฟเวอร์อื่น จากนั้น StatsD จะล้างข้อมูลเมตริกทุกวินาทีไปยังอินสแตนซ์ Graphite ที่อยู่บนเซิร์ฟเวอร์เดียวกัน จากนั้นฉันดูจำนวนของเมทริกที่ถูกส่งโดยชุดทดสอบจริงและจำนวนของกราไฟต์ที่ได้รับเพื่อตรวจสอบการสูญหายของแพ็คเก็ตระหว่างชุดทดสอบและกราไฟท์ อย่างไรก็ตามฉันสังเกตเห็นว่าบางครั้งฉันก็มีอัตราการส่งแพ็คเก็ตขนาดใหญ่มาก (โปรดทราบว่ามันถูกส่งด้วยโปรโตคอล UDP) ตั้งแต่ 20-50% ดังนั้นเมื่อฉันเริ่มดูว่าแพ็กเก็ตเหล่านี้ถูกทิ้งไปอย่างไรเนื่องจากเป็นปัญหาด้านประสิทธิภาพของ StatsD ดังนั้นฉันจึงเริ่มบันทึกการวัดในทุกส่วนของระบบเพื่อติดตามว่าการลดลงนี้เกิดขึ้นที่ไหน และนี่คือสิ่งที่แปลก ฉันใช้tcpdumpเพื่อสร้างไฟล์จับภาพซึ่งฉันตรวจสอบหลังจากการทดสอบเสร็จสิ้นแล้ว แต่เมื่อใดก็ตามที่ฉันทำการทดสอบด้วยการรัน tcpdump การสูญเสียแพ็กเก็ตนั้นแทบจะไม่มีเลย! ดูเหมือนว่า tcpdump กำลังเพิ่มประสิทธิภาพการทดสอบของฉันและฉันไม่สามารถหาสาเหตุและวิธีการนี้ได้ ฉันใช้คำสั่งต่อไปนี้เพื่อบันทึกข้อความ tcpdump บนทั้งเซิร์ฟเวอร์และไคลเอนต์: tcpdump -i any -n port 8125 -w …

13 performance  udp  tcpdump  graphite  statsd 

ฉันมีกลุ่มของเครื่องที่ใช้คาร์บอนและกราไฟต์ที่ฉันต้องปรับขนาดสำหรับการจัดเก็บข้อมูลเพิ่มเติม แต่ฉันไม่แน่ใจว่าฉันจำเป็นต้องเพิ่มหรือลดขนาด คลัสเตอร์ปัจจุบันประกอบด้วย: 1 รีเลย์โหนด: รับเมตริกทั้งหมดและส่งต่อไปยังโหนดหน่วยเก็บข้อมูลที่เกี่ยวข้อง 6 โหนที่เก็บข้อมูล: เก็บไฟล์ Whisper DB ทั้งหมด ปัญหาคือว่าดูเหมือนว่าเมื่อดิสก์ได้รับในการใช้งาน 80% ประสิทธิภาพการทำงานลดลงจากหน้าผา กลุ่มการเขียน IOPS ลดลงจาก 13k ใกล้คงเป็นค่าเฉลี่ยที่วุ่นวายมากขึ้นประมาณ 7k และ IOwait เวลาเฉลี่ย 54% ฉันได้ดูผ่าน repo การตั้งค่าของเราและไม่มีการเปลี่ยนแปลงตั้งแต่ต้นเดือนเมษายนดังนั้นนี่ไม่ใช่ผลลัพธ์ของการเปลี่ยนแปลงการกำหนดค่า คำถาม: การเพิ่มขนาดดิสก์จะทำให้ประสิทธิภาพของ IO กลับมาอยู่ภายใต้การควบคุมหรือฉันต้องเพิ่มโหนดหน่วยเก็บข้อมูลเพิ่มเติมหรือไม่ หมายเหตุ:ไม่มี SSD ที่นี่มีแกนหมุนเยอะมาก กราฟที่เกี่ยวข้อง: สถิติและสิ่งต่าง ๆ : e2freefrag: [root@graphite-storage-01 ~]# e2freefrag /dev/vda3 Device: /dev/vda3 Blocksize: 4096 bytes Total …

11 linux  filesystems  ext4  graphite 

เราใช้กราไฟท์เพื่อติดตามประวัติการใช้งานดิสก์เมื่อเวลาผ่านไป ระบบการแจ้งเตือนของเราพิจารณาข้อมูลจากกราไฟท์เพื่อแจ้งเตือนเราเมื่อพื้นที่ว่างต่ำกว่าจำนวนบล็อกที่กำหนด ฉันต้องการได้รับการแจ้งเตือนที่ชาญฉลาด - สิ่งที่ฉันสนใจจริงๆคือ "ฉันต้องใช้เวลานานแค่ไหนก่อนที่ฉันจะต้องทำอะไรบางอย่างเกี่ยวกับพื้นที่ว่าง" เช่นถ้าแนวโน้มแสดงว่าใน 7 วันฉันจะหมดดิสก์ เว้นวรรคแล้วยกคำเตือนหากน้อยกว่า 2 วันให้เพิ่มข้อผิดพลาด อินเทอร์เฟซแดชบอร์ดมาตรฐานของกราไฟต์นั้นค่อนข้างฉลาดด้วยอนุพันธ์และ Holt Winters Confidence bands แต่จนถึงตอนนี้ฉันยังไม่พบวิธีแปลงสิ่งนี้เป็นตัวชี้วัดที่สามารถดำเนินการได้ ฉันยังพอใจกับการบดตัวเลขด้วยวิธีอื่น ๆ (เพียงดึงตัวเลขดิบจากแกรไฟต์และเรียกใช้สคริปต์เพื่อทำเช่นนั้น) ปัญหาหนึ่งคือกราฟไม่ราบรื่น - ไฟล์เพิ่มและลบ แต่แนวโน้มทั่วไปเมื่อเวลาผ่านไปคือการเพิ่มการใช้พื้นที่ว่างในดิสก์ดังนั้นอาจมีความจำเป็นต้องดูค่าต่ำสุดในตัวเครื่อง (หากดูที่เมตริก "ดิสก์ฟรี" ) และวาดแนวโน้มระหว่างราง มีใครทำเช่นนี้?

9 disk-space-utilization  monitoring  graphite 

ในช่วงไม่กี่วันที่ผ่านมาฉันพยายามเข้าใจความแปลกประหลาดที่เกิดขึ้นในโครงสร้างพื้นฐานของเรา แต่ฉันไม่สามารถคิดได้ว่ามันเป็นของเราดังนั้นฉันจึงหันไปหาพวกคุณเพื่อให้คำแนะนำ ฉันสังเกตเห็นใน Graphite, spikes ใน load_avg ซึ่งเกิดขึ้นกับระเบียบที่เป็นอันตรายถึงชีวิตประมาณ 2 ชั่วโมง - มันไม่ได้เกิดขึ้น 2 ชั่วโมง แต่มันก็ปกติมาก ฉันกำลังแนบสกรีนช็อตของสิ่งนี้ที่ฉันได้รับจาก Graphite ฉันติดขัดในการตรวจสอบเรื่องนี้ - ความสม่ำเสมอของสิ่งนี้ทำให้ฉันคิดว่ามันเป็นงาน cron หรืออะไรทำนองนั้น แต่ไม่มี cronjobs ทำงานบนเซิร์ฟเวอร์เหล่านี้ - จริง ๆ แล้วนี่คือ VMs ที่ทำงานในคลาวด์ Spacespace สิ่งที่ฉันกำลังมองหาคือสิ่งบ่งชี้ว่าอาจเป็นสาเหตุของปัญหาเหล่านี้และวิธีการตรวจสอบเพิ่มเติม เซิร์ฟเวอร์ไม่ได้ใช้งานพอสมควร - นี่เป็นสภาพแวดล้อมที่มีการจัดเตรียมดังนั้นจึงแทบไม่มีการรับส่งข้อมูลเข้ามา / ไม่ควรมีการโหลด เหล่านี้คือ VM เสมือน 4 คอร์เสมือน สิ่งที่ฉันรู้แน่นอนคือเรากำลังรวบรวมตัวอย่างของกราไฟต์ทุก ๆ 10 วินาที แต่ถ้านั่นเป็นสาเหตุของการโหลดฉันคาดว่ามันจะสูงอย่างต่อเนื่องมากกว่าที่จะเกิดขึ้นทุก ๆ 2 …

9 linux  ubuntu  high-load  graphite