Blog: Classier Twitter threads - Tag NewRelic

V DámeJídlo.cz děláme tak trochu distribuovaně. A můžu za to hlavně já, protože se mi nechtělo stěhovat do Prahy. Takže už rok a půl komunikujeme přes Github, občas přes emaily a hlavně přes chat.

První co se zavedlo s mým příchodem do firmy, byl skype chat pro všechny devs. Což na lidskou komunikaci funguje výborně, píšete hlavně do společného, aby všichni měli přehled na čem se dělá a občas si něco pořešíte privátně.

Ovšem na komunikaci programátorů to funguje otřesně. Proč? Když něco vyvíjíte, tak chcete mít co největší přehled, o co nejvíce věcech a ideálně na jednom místě. Do skype se dost složite píšou roboti, co vám pošlou do společného zprávu vždy, když někdo pouští deploy nebo spadne build.

Takže jsme se přes rok rozhoupávali, že přejdeme na vlastní jabber chat. A protože probíráme supertajné věci, měl to být samozřejmě náš vlastní server, ideálně na vlastní VPS. Potom že si tam nahodíme robota a budeme žít šťastně až do smrti. To samozřejmě ztroskotalo na tom, že se to buďto opakovaně odkládalo, nebo se to nikomu nechtělo nastavovat.

Zkoušeli jsme i gitter, který se našim představám blížil úplně nejvíc, ale vydrželi jsme to dva dny a bugy a nedostatky převládly a vrátili jsme se ke skype.

A pak jsme objevili HipChat a v ten moment byla zabita poslední naděje na jabber server, protože tomuhle se těžko konkuruje.

HipChat

Je cloud-based služba, kterou provozuje Atlassian a má hromadou hotových integrací. To, že má klienty pro všechny platformy na telefonech (iOS i Android) i počítačích (Mac, Win i Linux), už je jen třešnička. A ještě navíc je strašně levnej.

V dalších pár odstavích si ukážeme, jak ho nastavit a příklady několika integrací, které používáme.

Notifikace: Travis

Do .travis.yml stačí přidat pár řádků

notifications:
  hipchat:
    rooms:
      - secret-api-key@room-number
    template:
      - '<a href="%{build_url}">build#%{build_number}</a> on %{branch} by %{author}: %{message}<br> - %{commit_message} (<a href="%{compare_url}">%{commit}</a>)'
    format: html
  email: false

A už to lítá

Travis notifikace v chatu

Notifikace: Vlastní deploy

Hipchat má našlapaný api a můžete si tam poslat co chcete. My máme deploy script v bashi, takže notifikace posíláme takto

#!/bin/bash
function hipchat_notify() {
        export CHAT_NOTIFY="$1"

        CHAT_COlOR="$2"
        if [ -z "$CHAT_COlOR" ]; then
                CHAT_COlOR="yellow"
        fi

        curl -X POST \
                -d "message=$(php -r 'echo rawurlencode(getenv("CHAT_NOTIFY"));')" \
                "https://api.hipchat.com/v1/rooms/message?room_id=room-number&from=Deploy&message_format=html&notify=1&color=$CHAT_COLOR&format=json&auth_token=secret-api-key" \
                >/dev/null 2>/dev/null || echo "HipChat notification failed"
}

# ...

hipchat_notify "$GIT_MERGE_AUTHOR just deployed <a href=\"https://github.com/damejidlo/damejidlo/commit/$REVISION\">$REVISION</a> to <a href=\"https://$DOMAIN\">$(hostname)</a>, downtime was $DOWNTIME_SEC seconds"

Deploy notifikace v chatu

Notifikace: Github

Na githubu je na HipChat hotová integrace, takže stačí nastavit token a místnost. A doporučuji vypnout komentáře (dělá to strašnej spam)

Nastavení github hooku

Každý commit do masteru se ukáže v chatu, takže hovada co nedělají pullreqesty se hned prozradí

Github notifikace v chatu

Osobně mám vyplé emaily z githubu, takže mi moc vyhovuje, že všechno vidím v chatu a nemusím chodit kontrolovat notifikace. Uvidíte taky všechny otevření/zavření issue a otevření/merge/close pullrequestů, editaci wiki atd.

Notifikace: NewRelic

Nejprve si založíme “notifikační kanál”

Potom ho přiřadíme aplikaci

A pak už si jen užíváte spam

Newrelic notifikace v chatu

Blbinky

Podle mě naprostá killer feature je taky inlinování. Umí issues a commity z Githubu (pokud jsou public), Tweety, Youtube videa, a hlavně gify

Screenshot gifu se bohužel nehýbe :(

Pokud máte také vývojový tým přes více měst/států, jak komunikujete vy?

Continue reading ...

Má Vaše aplikace víc než pět návštěv denně? Pak není od věci nějakým způsobem monitorovat, co se děje. Za tímhle účelem vznikají nejrůznější placené i opensource řešení. Některé lepší, některé horší. Několik měsíců zpátky jsem řešil, jaký monitoring nasadím na svoje sexy VPS od Wedosu (na kterém běží i tento blog).

@wedoscom Monitoring! To je jediná věc, která mi chybí! Nepotřebuju návštěvnost, ani analytiku - stačí vytíženost zdrojů na VPS.

— Filip Procházka (@ProchazkaFilip) June 18, 2012

Nebudu to protahovat, zvolil jsem nakonec NewRelic, který mi poradil Honza Doleček. Jeho jediné mínus je, že je docela drahý. Ale po měsíci trial verze a tričku zdarma už se mi nechtělo nikam migrovat.

Pak jsem dlouho monitoring neřešil a teď máme NewRelic i v Damejidlo.cz. Na své VPS mám pár malých webíků, ale tady už začíná být kritické, mít vše pod dohledem.

Před pár dny jsem objevil killer feature NewRelicu a o tu bych se s Vámi chtěl zde podělit. Je to jeho PHP API. Abych to trošku rozvedl, NewRelic se instaluje tak, že do phpčka zavedete modul a nastavíte IDčko aplikace. V ten moment začne rozsíření odesílat data na jejich servery a já se můžu kochat krásnými grafy :)

A to prý je Doctrine2 pomalá ;)

Stejným způsobem, prostou instalací balíku, jde rozchodit i monitoring systému.

Náš dev server se moc nenadře :)

S chytrými frameworky je ale problém..

a určitě Vám hned dojde jaký, při pohledu na tento screenshot.

NewRelic nerozlišuje adresy, protože všechno jde na index.php

Další “problém” je, že Nette Framework sám řeši všechny chyby a výjimky a NewRelic se tak vůbec v tomto nedostane ke slovu. Když tedy server začne spamovat logy laděnkama, dozvím se to až když mi přijde email, který ani navíc přijít nemusí.

A tady přichází k řeči PHP API, na které mě též upozornil Honza. Chtěl jsem to mít cool, tak jsem řešení založil “na svém Event systému”:/blog/eventy-a-nette-framework.

Tohle API pokrývá rozlišení jednotlivých requestů, logování errorů a výjimek a umí taky označit požadavek jako “proces na pozadí”((background job)). Což není špatné rozlišit, protože vydatně používáme CLI scripty přes Symfony Consoli, pouštené cronem a nechceme, aby se nám pletly do frontend requestů. Byť snad všechny zatím roztřídil správně, jistota je jistota :)

Kompletní řešení tedy vypadá takto

namespace NewRelic;

use Kdyby;
use Nette;
use Nette\Application\Application;
use Nette\Application\Request;
use Nette\Diagnostics\Debugger;

class NewRelicProfilingListener extends Nette\Object implements Kdyby\Events\Subscriber
{
    public function getSubscribedEvents()
    {
        return array(
            'Nette\\Application\\Application::onStartup',
            'Nette\\Application\\Application::onRequest',
            'Nette\\Application\\Application::onError'
        );
    }

    public function onStartup(Application $app)
    {
        if (!extension_loaded('newrelic')) {
            return;
        }

        // registrace vlastního loggeru na errory
        Debugger::$logger = new Logger;
        Debugger::$logger->directory =& Debugger::$logDirectory;
        Debugger::$logger->email =& Debugger::$email;
    }

    public function onRequest(Application $app, Request $request)
    {
        if (!extension_loaded('newrelic')) {
            return;
        }

        if (PHP_SAPI === 'cli') {
            // uložit v čitelném formátu
            newrelic_name_transaction('$ ' . basename($_SERVER['argv'][0]) . ' ' . implode(' ', array_slice($_SERVER['argv'], 1)));

            // označit jako proces na pozadí
            newrelic_background_job(TRUE);

            return;
        }

        // pojmenování požadavku podle presenteru a akce
        $params = $request->getParameters();
        newrelic_name_transaction($request->getPresenterName() . (isset($params['action']) ? ':' . $params['action'] : ''));
    }

    public function onError(Application $app, \Exception $e)
    {
        if (!extension_loaded('newrelic')) {
            return;
        }

        if ($e instanceof Nette\Application\BadRequestException) {
            return; // skip
        }

        // logovat pouze výjimky, které se dostanou až k uživateli jako chyba 500
        newrelic_notice_error($e->getMessage(), $e);
    }
}

A ještě Logger

namespace NewRelic;

use Nette;

class Logger extends Nette\Diagnostics\Logger
{
    public function log($message, $priority = self::INFO)
    {
        $res = parent::log($message, $priority);

        // pouze zprávy, které jsou označené jako chyby
        if ($priority === self::ERROR || $priority === self::CRITICAL) {
            if (is_array($message)) {
                $message = implode(' ', $message);
            }
            newrelic_notice_error($message);
        }

        return $res;
    }
}

Pokud máte v aplikaci Kdyby/Events, tak je rozběhání listeneru otázkou tří řádků konfigurace

services:
    newRelicListener:
        class: NewRelic\NewRelicProfilingListener
        tag: [kdyby.subscriber]

Co se týče logování chyb, má NewRelic do laděnky ještě světelné míle daleko. To co tam je teď, připomíná spíše brášku log/error.log. Pro laděnky si tedy stále musím dojít do logu na server. Je ale super vidět prolnutí chybovosti vzhledem k počtu požadavků. Určitě tedy stojí za to, posílat chyby do NewRelicu.

Na druhou stranu, chudý rozbor chyb je vynahrazený luxusním profilerem, který automaticky loguje requesty, které trvají déle než by měly a velice přesně, až možná doterně, upozorňuje na úzká hrdla aplikace.

Výsledek

Nyní už uvidím jednotlivé requesty podle presenteru a akce

Requesty seskupené podle presenterů

stejně tak procesy, které probíhají na pozadí

Procesy na pozadí

a také všechny chyby, které se v aplikaci vyskytnou.

Procento chyb vzhledem k requestům

Naštěstí jich tam moc není :)

Za mě můžu NewRelic jedině doporučit. U větších aplikací je to must have. Jak monitorujete svoje aplikace vy?

Continue reading ...