errno=ECONNREFUSED. Failed to connect to the newrelic-daemon

ตอนสั่ง start newrelic PHP Agent แล้วปรากฏว่ารันไม่ขึ้น ซึ่งไม่เคยเจอปัญหานี้มาก่อน เลยไปค้นหาวิธีแก้ พบว่ามีทางแก้สองแบบ

แบบแรก

แก้ไขไฟล์ 20-newrelic.ini จาก

newrelic.daemon.port = "/tmp/.newrelic.sock"

เป็น

newrelic.daemon.port = "@newrelic-daemon"

แล้วสั่ง


service php5-fpm restart
service newrelic-daemon restart

แต่ผมลองแล้วไม่ได้ผล เลยต้องหาวิธีใหม่ได้แบบที่สองคือ

แบบที่สอง

1. พิมพ์ 

getent group newrelic

จะได้ผลลัพธ์ประมาณ newrelic:x:GroupID: ออกมา ให้จำค่า GroupID ไว้สำหรับใช้ต่อไป

2. แก้ไขไฟล์ /etc/sysctl.conf โดยเพิ่ม ข้อมูลดังนี้เข้าไป

fs.proc_can_see_other_uid = 0
fs.proc_super_gid = GroupID

ข้อควรระวังคือ fs.proc_super_gid สามารถใส่ GroupID ได้เพียงอันเดียว ถ้ามี fs.proc_super_gid อยู่ก่อนแล้วให้คุณสร้าง group ใหม่ขึ้นมาแล้วใส่ users ที่ต้องการใช้งานเข้าไปใน group ให้ครบทุก user แล้วใช้ group ใหม่นั้นแทนไปเลย แต่ถ้าไม่เคยสั่ง fs.proc_super_gid มาก่อนก็ไม่ต้องสนใจส่วนนี้

3. 

sysctl -p

4. 

service php5-fpm restart
service newrelic-daemon restart

5. เสร็จเรียบร้อย

Newrelic ตอนนี้ขยายบริการใหญ่โตมาก แบ่งการ Monitor หลักๆ ได้ออกเป็น

1. Web App Monitoring – ซึ่งมันคือบริการแรกเริ่มของ New Relic ที่ผม Review ไปเมื่อ 2 ปีที่แล้ว
2. Mobile App Monitoring – ตรงนี้ผมยังไม่เคยใช้บริการ แต่เข้าใจว่าเน้นการ monitor ด้านข้อมูล Network ที่ส่งเข้าออกจากตัวมือถือ
3. Server Monitoring – ตัวนี้คือที่ผมจะพูดถึงวันนี้

สิ่งแรกที่ต้องมี แน่นอนคือ CPU และ Memory ที่ใช้งานไปของเครื่อง (ในรูปปรับให้แสดง 24 ชม. ซึ่งจริงๆ สามารถปรับเป็น 30 นาทีแล้วดูผลได้เกือบ Real time)

อันนี้ Disk I/O และ Network I/O ซึ่งจะแยก disk เป็นลูกๆ ให้เห็นอย่างชัดเจน

เกิด Event อะไรอันตรายไหมในช่วงเวลาที่ผ่านมา เช่น Mem เต็ม CPU ทะลัก disk ระเบิด บลาๆ

รูปนี้แสดงให้เห็นว่า process อะไรกิน Memory กิน CPU มากที่สุด ในช่วงเวลาต่างๆ เห็นกันชัดๆ ไปเลยว่าใครเป็นตัวปัญหาของ server เช่นในรูปผมสั่ง backup database ช่วงตี 4 จะเห็นว่า process lbzip2 (บีบอัดไฟล์ backup) ทำงานหนักที่สุด (นอกนั้น node กินเรียบ 55+)

ตัวนี้แสดงกราฟเป็นราย process อย่างในรูปคือ php-fpm process ที่ใช้รับ Frontend หน้าเว็บ ซึ่งมี Running instance count หรือก็คือมีจำนวน process นี้กี่ตัวให้ดูด้วย ตรงนี้เอาไว้ Monitor การ spawn children ของ php-fpm ได้เป็นอย่างดี

รูปนี้เป็น Disk I/O ที่ละเอียดขั้นว่าในช่วงเวลาต่างๆ มีอัตราการอ่านเขียนที่กี่ MB/S และยังดูค่า IOPS ได้อีกด้วย!! (ใครใช้ AWS จะเอามาคำนวณดูสถิติย้อนหลังเพื่อช่วยสร้างเครื่องที่เหมาะสมได้ดีมาก!)

รายชื่อ server หลายๆ เครื่องเท่าที่มีทั้งหมด ดูภาพรวมอาณาจักรของเราได้ตรงนี้

และนี่เป็นหนึ่งใน Feature ที่ผมชอบมากที่สุดครับ อีเมล์แจ้งเตือนเราเมื่อ CPU, Mem, Disk I/O เกินกี่ % ซึ่งเราตั้งค่าที่ต้องการให้เตือนได้เองอย่างอิสระ เมื่อเราได้รับการแจ้งเตือนถึงปัญหาที่กำลังจะเกิดแต่เนิ่นๆ เราก็จะสามารถเตรียมรับมือและรีบตรวจหาสิ่งผิดปกติในเวลานั้นได้ทันท่วงทีก่อนที่เครื่องจะระเบิดได้

เอ๋? ยังไม่พอใจอีกเหรอ? เค้ามี Plugin ให้ install ใช้ฟรีตามแต่ application ที่ใช้เลยนะเออ! พวกนี้จะเป็นบริษัทอื่น Third Party ที่มาร่วมแจมพัฒนาตัวส่งข้อมูลมายิงเข้า Newrelic แล้วทาง Newrelic จะช่วยเก็บข้อมูลสถิติกราฟย้อนหลังให้ นั่นหมายความว่าอนาคต เราอาจจะ Monitor ได้ทุกโปรแกรมบนโลกใบนี้ด้วยพลังของ Third Party Plugin! และน่าจะฟรีทั้งหมดด้วย!

ตัวอย่างในรูปผม Install Plugin Monitor Memcached ครับ ทำให้ผมทราบสถิติการใช้งานคำสั่งภายใน Memcached ดังรูปเลย (set, get,delete มากี่รอบต่อนาที)

และสุดท้ายก็คือการดูข้อมูลย้อนหลังครับ ตรงนี้จะเป็นจุดแตกต่างที่สำคัญที่สุดระหว่างการใช้ฟรีและจ่ายเงิน เพราะใช้ฟรีจะดูย้อนหลังได้แค่ 1 วัน หากเสียเงินจะดูได้ 7 วัน หรือ 3 เดือนตามแต่ package ซึ่ง Feature ที่ว่ามาตั้งแต่ต้นทั้งหมดสามารถใช้ได้ฟรี! แค่จะดูได้แค่ 1 วัน ซึ่งเอาเข้าจริงก็เพียงพอต่อการแก้ปัญหาเฉพาะหน้าได้มากแล้ว

แถมอีกนิด เค้ามี app มือถือให้โหลดมาใช้ฟรีด้วยเช่นกัน หากอยู่นอกสถานที่ก็ยังดูข้อมูล Server ได้ตลอดเวลา ที่สำคัญเวลามีอะไรพังขึ้นมาก็มี Push Notification แจ้งเตือนอีกต่างหาก พระเจ้าจอร์จ มันยอดมาก!

ใครน้ำลายไหล อยากจะได้ก็จิ้มเลยครับ http://www.newrelic.com สมัครวันนี้แม้จะ package ฟรีจะแถมเสื้อฟรีและคอปเตอร์วิทยุบังคับฟรี! ส่งไปรษณีข้ามโลกมาเลยทีเดียว (ทำไมต้องคอปเตอร์ฟะ) เอ๊ะ! ผมเป็น Sale ให้ Newrelic ตั้งแต่เมื่อไหร่ 55+

ลองพิมพ์คำสั่งด้านล่างกัน โดย -n คือจำนวน request ทั้งหมดที่จะยิง และ -c คือจำนวน concurrent connection ที่จะใช้ (คือจำลองว่ามีผู้ใช้เข้าใช้งานพร้อมกันกี่คนนั่นเอง) โดยเวลาพิมพ์ชื่อเว็บอย่าลืมพิมพ์ / ต่อท้ายด้วยไม่งั้นจะยิงไม่ได้ ผลจะเป็นดังนี้

ab -n 100 -c 10 http://www.sanook.com/

This is ApacheBench, Version 2.3 <$Revision: 655654 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.sanook.com (be patient)…..done

Server Software:        Apache

Server Hostname:        www.sanook.com

Server Port:            80

Document Path:          /

Document Length:        154040 bytes

Concurrency Level:      10

Time taken for tests:   2.523 seconds

Complete requests:      100

Failed requests:        0

Write errors:           0

Total transferred:      15435200 bytes

HTML transferred:       15404000 bytes

Requests per second:    39.64 [#/sec] (mean)

Time per request:       252.255 [ms] (mean)

Time per request:       25.225 [ms] (mean, across all concurrent requests)

Transfer rate:          5975.49 [Kbytes/sec] received

Connection Times (ms)

min  mean[+/-sd] median   max

Connect:        2    3   1.5      2      16

Processing:    43  222 180.5    154     885

Waiting:        2   11  40.4      3     210

Total:         45  225 181.0    156     891

Percentage of the requests served within a certain time (ms)

50%    156

66%    275

75%    294

80%    313

90%    494

95%    542

98%    707

99%    891

100%    891 (longest request)

จากผลลัพท์นี้จะเห็นว่าได้ sanook.com รับได้ 39.64 Request/sec และใช้เวลาตอบสนองคือ min 45, mean 225, max 891 millisec ซึ่งเราสามารถทดลองเพิ่มค่า -n และ -c เพื่อเพิ่มขนาดจำนวน load ที่จะยิงได้ตามใจ โดยผมลองยิง server ตัวเอง (ควรจะยิงจากเครื่องอื่นที่ไม่ใช่ webserver เพราะ ab นั้นกินพลัง cpu ด้วยเช่นกัน จะทำให้ค่าที่วัดคลาดเคลื่อนได้ถ้ารันในเครื่องเดียวกับ webserver) ด้วยค่า -n 1000 – c 100 (มีคนเข้าพร้อมกัน 100 คน ทดสอบเมื่อคนเข้าเยอะมากๆ นั่นเอง) และเว็บผมได้ติด Newrelic ดู performance อยู่กรณีมีคนเข้าเยอะผลจะเป็นอย่างไร ได้ผลเป็น 40.20 Request/sec ใช้เวลาตอบสนอง min 215, mean 2313, max 3877 (ยิงด้วยเครื่องที่อยู่ในวง network เดียวกัน) และได้ผลจาก newrelic ออกมาดังรูป

จากรูปก็จะเห็นว่าเมื่อมี Request เพิ่มมากขึ้นแล้ว จะทำให้ php ช้าขึ้นมากอย่างเห็นได้ชัด(กราฟที่แสดงส่วนของ php นี้รวมเวลาทั้ง webserver และ php ไว้ด้วยกัน) ส่วน Database ของผมแม้จะมี Request มากขึ้น แต่ก็ไม่ส่งผลให้ช้าลงมากนัก จึงเป็นอันสรุปได้ง่ายๆ เลยว่า Bottleneck ของ application ตัวนี้เวลาคนเข้าเยอะๆ อยู่ที่ php/webserver นั่นเอง โดยสามารถตัดประเด็นเรื่อง Database ออกไปได้เลย มา optimize ที่ตัว code php และการ set ค่าต่างๆ ของตัว server เองต่อไป ซึ่งตัวผมเองได้ใช้เอามาเปรียบเทียบการเปลี่ยน webserver จาก apache เป็น nginx ก็เห็นผลได้ค่อนข้างชัดเจนเช่นกัน จะเห็นได้ว่า ab มีประโยชน์มากจริงๆ ครับ