@harrasteblogi JUURI NYT
--:--

Tilaa uutiskirje

Saat tuoreimmat 10 uusinta artikkelia kerran viikossa sähköpostiisi.

Tilaa uutiskirje

Kuinka rakentaa oma logging-järjestelmä WordPress-pluginilleHyvä logging-järjestelmä on yksi tärkeimmistä asioista vakaan WordPress-pluginin rakentamisessa. Ilman kunnollista lokitusta virheiden debuggaus muuttuu vaikeaksi, suorituskykyongelmien syyt jäävät piiloon ja integraatioiden monitorointi on lähes mahdotonta.

Moni plugin käyttää pelkkää:

error_log('Something failed');

Tämä toimii pienissä projekteissa, mutta ei skaalaudu tuotantoympäristöihin.

Moderni logging-järjestelmä mahdollistaa:

  • keskitetyn virhehallinnan
  • debuggaamisen
  • auditoinnin
  • API-monitoroinnin
  • suorituskyvyn seurannan
  • turvallisuuslogituksen

Mitä logging-järjestelmä tekee

Hyvä logger:

  • tallentaa tapahtumat
  • luokittelee logit
  • tukee eri severity-tasoja
  • mahdollistaa haun ja analytiikan
  • minimoi suorituskykyvaikutuksen

Tyypillinen flow:

Application Event
↓
Logger
↓
Storage
↓
Monitoring

1. Rakenna oma Logger-luokka

Perusrakenne:

class Logger {

    public function info($message) {

        $this->write('INFO', $message);
    }

    public function error($message) {

        $this->write('ERROR', $message);
    }

    protected function write($level, $message) {

        error_log("[{$level}] {$message}");
    }
}

2. Käytä severity-tasoja

Yleisimmät:

DEBUG
INFO
WARNING
ERROR
CRITICAL

Näin logit voidaan suodattaa helposti.

3. Structured logging

Pelkkä tekstiloki on huono pitkässä käytössä.

Parempi:

{
  "level": "ERROR",
  "message": "Payment failed",
  "order_id": 123
}

Structured logging helpottaa:

  • hakua
  • analytiikkaa
  • monitorointia

4. JSON logging

protected function write($level, $message, array $context = []) {

    $entry = [
        'level' => $level,
        'message' => $message,
        'context' => $context,
        'timestamp' => time()
    ];

    error_log(json_encode($entry));
}

5. Context-data on tärkeää

Huono:

API failed

Parempi:

$logger->error(
    'API request failed',
    [
        'endpoint' => '/orders',
        'status' => 500
    ]
);

6. Älä loggaa kaikkea

Liiallinen logging:

  • kasvattaa levytilaa
  • hidastaa sovellusta
  • tekee analysoinnista vaikeaa

Trackkaa:

  • virheet
  • tärkeät eventit
  • integraatiot
  • security-tapahtumat

7. Tiedostopohjainen logging

Yksinkertainen ratkaisu:

/wp-content/uploads/plugin-logs/

Kirjoitus:

file_put_contents(
    $file,
    $message,
    FILE_APPEND
);

8. Käytä log rotationia

Ilman rotaatiota:

log file = useita gigatavuja

Ratkaisut:

  • daily logs
  • max file size
  • cron cleanup

9. WordPress debug.log ei riitä

wp-content/debug.log:

  • täyttyy nopeasti
  • sisältää kaiken
  • vaikea analysoida

Pluginin kannattaa käyttää omaa loggeria.

10. Database logging

Mahdollinen mutta ei aina hyvä idea.

Custom table:

wp_plugin_logs

Hyödyllinen:

  • audit trailiin
  • admin vieweriin

Huono:

  • erittäin korkeassa volyymissa

11. Async logging

Raskas logging voi hidastaa requesteja.

Parempi:

Queue
↓
Background worker
↓
Write logs

12. REST API logging

Trackkaa:

  • endpointit
  • statuskoodit
  • response times
  • failed requests

Esimerkki:

$logger->info(
    'REST request',
    [
        'route' => $request->get_route()
    ]
);

13. WooCommerce logging

WooCommerce sisältää loggerin:

$logger = wc_get_logger();

Mutta custom logger tarjoaa enemmän kontrollia.

14. PSR-3 standardi

Paras moderni ratkaisu.

Interface:

Psr\Log\LoggerInterface

Hyödyt:

  • standardointi
  • yhteensopivuus
  • helppo vaihtaa provideria

15. Monolog WordPressissä

Suosittu ratkaisu:

composer require monolog/monolog

Mahdollistaa:

  • file logging
  • Slack logging
  • syslog
  • external services

16. Security logging

Trackkaa:

  • failed loginit
  • permission virheet
  • API abuse
  • epäilyttävät requestit

Mutta älä loggaa:

  • salasanoja
  • access tokeneita
  • henkilötietoja

17. Performance logging

Hyödyllinen optimoinnissa:

$start = microtime(true);

Lopuksi:

$logger->info(
    'Import completed',
    [
        'duration' => microtime(true) - $start
    ]
);

18. Error handling integration

Yhdistä logger exceptioneihin:

try {

} catch (\Exception $e) {

    $logger->error($e->getMessage());
}

19. Remote logging

Enterprise-ratkaisuissa:

WordPress
↓
Log Aggregator
↓
ELK / Datadog / Grafana

20. Logging levels ympäristöittäin

Development:

DEBUG enabled

Production:

INFO+

21. GDPR ja logging

Älä tallenna:

  • henkilötunnuksia
  • maksutietoja
  • access tokeneita
  • raw user dataa

Maskaa tarvittaessa data.

22. Yleisimmät virheet

  • liikaa loggingia
  • sensitive datan tallennus
  • ei log rotationia
  • sync logging kaikkialla
  • pelkkä error_log käyttö
  • ei severity-tasoja
  • ei structured loggingia

23. Paras logging-arkkitehtuuri

Moderni WordPress logging stack:

Application
↓
PSR-3 Logger
↓
Async Queue
↓
Structured JSON Logs
↓
Monitoring Platform

Yhteenveto

Hyvä logging-järjestelmä tekee WordPress-pluginista huomattavasti helpomman ylläpitää, debugata ja monitoroida. Structured logging, severity-tasot ja async-käsittely mahdollistavat skaalautuvan ratkaisun ilman että suorituskyky kärsii.

Kun logging rakennetaan osaksi pluginin arkkitehtuuria alusta asti, ongelmat löytyvät nopeammin ja tuotantoympäristö pysyy hallittavana myös suurissa järjestelmissä.

🍪