LLM Logging Best Practices: 9 Κανόνες που Ακολουθούμε στην Παραγωγή [2026]

LLM Logging Best Practices: 9 Κανόνες που Ακολουθούμε στην Παραγωγή [2026]

Αυτές οι εννέα best practices LLM logging είναι οι κανόνες που τρέχει πραγματικά το production stack μας: καταγράφουμε 1,2 εκατομμύρια LLM αιτήματα τον μήνα σε τέσσερις υπηρεσίες και κάθε ένα καταλήγει στο Grafana Loki ως μία γραμμή JSON με model, tokens, latency, cost_usd και trace_id. Το structlog 25.4.0 γράφει την εγγραφή, το Presidio αφαιρεί πρώτα τα PII και όλο το pipeline είναι το μισό κομμάτι καταγραφής του stack παρατηρησιμότητας μας.

Βασικά Συμπεράσματα

• Καταγράψτε κάθε LLM αίτημα ως δομημένο JSON με 14+ ονοματισμένα πεδία, ποτέ ελεύθερο κείμενο.
• Αποκρύψτε τα PII πριν από την εγγραφή του log με το Presidio ή ισοδύναμο, όχι μετά.
• Προσαρτήστε σε κάθε trace τα attributes των σημασιολογικών συμβάσεων GenAI του OpenTelemetry.
• Στα 1 εκατ. αιτήματα/ημέρα, τα ίδια 60GB κοστίζουν 108 $/μήνα στο Datadog, 30 $ στο Loki και 1,20 $ στο ClickHouse.

Τι σημαίνει πραγματικά το LLM Logging (και γιατί το «απλά καταγράψτε τα πάντα» αποτυγχάνει)

Το LLM logging σημαίνει καταγραφή μιας δομημένης εγγραφής για κάθε αίτημα και απόκριση του μοντέλου: το prompt, την ολοκλήρωση, τον αριθμό tokens, τον χρόνο απόκρισης, το κόστος και το trace που τα συνδέει όλα με μια συνεδρία χρήστη. Δεν είναι καταγραφή υποδομής. Η CPU, η μνήμη και οι επανεκκινήσεις pod ανήκουν στο stack μετρικών σας. Αυτό το άρθρο καλύπτει μόνο την εγγραφή επιπέδου αιτήματος που σας επιτρέπει να αποσφαλματώνετε, να κοστολογείτε και να ελέγχετε τη συμπεριφορά του μοντέλου.

Το ένστικτο του «απλά καταγράψτε τα πάντα» αργεί να πεθάνει και κοστίζει ακριβά. Τα πλήρη prompts και οι ολοκληρώσεις σε 1 εκατομμύρια αιτήματα την ημέρα παράγουν περίπου 60GB κειμένου τον μήνα και ένα μέρος αυτού του κειμένου είναι PII πελατών που πλέον αποθηκεύετε επ' αόριστον. Η αρχή ελαχιστοποίησης δεδομένων του άρθρου 5 του GDPR απαιτεί τα προσωπικά δεδομένα να είναι «επαρκή, συναφή και περιορισμένα στο αναγκαίο» και η ακατέργαστη αποτύπωση prompt αποτυγχάνει σε αυτό το τεστ από την πρώτη μέρα. Η καταγραφή των πάντων δεν είναι στρατηγική. Είναι ευθύνη με μηνιαίο λογαριασμό.

Ποιοι είναι οι 9 κανόνες LLM Logging;

Εννέα κανόνες, με τη σειρά που θα τους εφαρμόζαμε: καταγραφή πλήρων prompts και αποκρίσεων με κατακερματισμένα αναγνωριστικά, παραγωγή δομημένου JSON, καταγραφή tokens και κόστους ανά αίτημα, προσάρτηση context trace του OpenTelemetry, απόκρυψη PII πριν από την εγγραφή, δειγματοληψία σε υψηλό όγκο, καθορισμός επιπέδων διατήρησης, διαχωρισμός συμβάντων ασφαλείας και δυνατότητα αναζήτησης στο αποτέλεσμα. Κάθε κανόνας παρακάτω συνοδεύεται από τον κώδικα ή τον πίνακα που τον επιβάλλει.

Κανόνας 1: Καταγράψτε το πλήρες Prompt και την απόκριση (με Hash, όχι ωμά PII)

Καταγράψτε το πλήρες prompt και την πλήρη ολοκλήρωση για κάθε αίτημα, επειδή τα μερικά logs είναι ο λόγος που καταλήγετε να κοιτάζετε ένα περιστατικό χωρίς καμία εγγραφή για το τι είδε πραγματικά το μοντέλο. Η μία εξαίρεση είναι η ταυτότητα: μην γράφετε ποτέ ωμά user IDs, email ή ονόματα μέσα στην εγγραφή. Αποθηκεύστε αντ' αυτού ένα hash SHA-256 του user ID. Ένα hash σάς επιτρέπει ακόμα να ανακατασκευάσετε το πλήρες ιστορικό συνεδρίας ενός χρήστη με μια offline αναζήτηση, ενώ η ίδια η γραμμή log παραμένει άχρηστη για οποιονδήποτε δεν πρέπει να τη διαβάσει. Η ίδια λογική ισχύει για τα system prompts: κάντε τα hash, καταγράψτε το hash και κρατήστε το plaintext στο prompt registry σας, όπου ήδη ελέγχεται με εκδόσεις.

Κανόνας 2: Χρησιμοποιήστε δομημένο JSON: κάθε πεδίο ονοματισμένο, τίποτα ελεύθερο κείμενο

Για τις best practices LLM logging σε Python ή σε οποιαδήποτε άλλη γλώσσα, η δομημένη καταγραφή σε JSON είναι το αδιαπραγμάτευτο: κάθε πεδίο ονοματισμένο, με τύπο και δυνατότητα αναζήτησης, τίποτα πεταγμένο ως formatted string. Μια γραμμή ελεύθερου κειμένου όπως INFO called gpt-4o, took 812ms μπορεί μόνο να γίνει grep. Μια εγγραφή JSON μπορεί να συγκεντρωθεί ανά μοντέλο, να αθροιστεί ανά κόστος και να ενωθεί με trace. Οι δικές του best practices παραγωγής του OpenAI προωθούν την ίδια ιδέα: καταγράψτε δομημένα metadata στο επίπεδο του SDK και όχι με print statements.

Αυτό είναι το schema που εκπέμπει κάθε υπηρεσία της Techsy, δεκατέσσερα πεδία:

{
  "request_id": "req_01J9XK4M7Q",
  "timestamp": "2026-07-18T09:24:31.482Z",
  "environment": "production",
  "model": "claude-sonnet-4-20250514",
  "prompt_tokens": 1284,
  "completion_tokens": 396,
  "latency_ms": 812,
  "cost_usd": 0.0098,
  "system_prompt_hash": "sha256:9f2c1a4e...",
  "user_id_hash": "sha256:b7e4d831...",
  "rag_sources": ["kb/pricing-2026.md", "kb/refund-policy.md"],
  "guardrail_result": "pass",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7"
}

Τρία πεδία αξίζουν μια σημείωση. Το cost_usd υπολογίζεται τη στιγμή του αιτήματος από τον αριθμό tokens και τη δημοσιευμένη τιμή του μοντέλου, ποτέ με νυχτερινή εργασία backfill. Τα δύο πεδία hash είναι ο συμβιβασμός του Κανόνα 1: συσχετίσιμα offline, αδιαφανή μέσα στο log. Και τα trace_id και span_id είναι τιμές trace-context του W3C, που είναι ακριβώς το αντικείμενο του Κανόνα 4.

Αν τέσσερις υπηρεσίες που καλούν παρόχους απευθείας ακούγονται σαν τέσσερα σημεία instrumentation, ένας proxy LiteLLM το συγκεντρώνει: ένα logging hook μπροστά από κάθε πάροχο.

Κανόνας 3: Καταγράψτε τον αριθμό Tokens και το κόστος ανά αίτημα

Η παρακολούθηση χρήσης tokens ανήκει στην ίδια τη γραμμή log, όχι σε μια εργασία warehouse που τρέχει αύριο. Κάθε πάροχος επιστρέφει τον αριθμό tokens εισόδου και εξόδου στην απόκριση. Πολλαπλασιάστε με την τιμή ανά token του μοντέλου εκείνη ακριβώς τη στιγμή και γράψτε το cost_usd στην εγγραφή. Οι τιμές αλλάζουν και διαφέρουν για cached έναντι φρέσκων input tokens, οπότε ο υπολογισμός του κόστους αργότερα με έναν στατικό τιμοκατάλογο ξαναγράφει σιωπηλά την ιστορία. Με κόστος σε κάθε γραμμή, το «ποιο feature είναι ακριβό;» γίνεται ερώτημα μιας γραμμής αντί για project του οικονομικού τμήματος και τροφοδοτεί απευθείας τη δουλειά για μείωση της δαπάνης σας σε LLM API.

Κανόνας 4: Προσαρτήστε Trace Context (GenAI Semconv του OpenTelemetry)

Μια γραμμή log χωρίς trace ID είναι ορφανή: μπορείτε να τη διαβάσετε, αλλά δεν μπορείτε να πείτε ποιο retry, ποιο βήμα RAG ή ποια σειρά χρήστη την παρήγαγε. Η λύση είναι οι σημασιολογικές συμβάσεις GenAI του OpenTelemetry, τα τυπικά ονόματα attributes για την οργάνωση κλήσεων μοντέλου. Εκπέμψτε το log μέσα σε ένα ενεργό span και τα trace_id και span_id προσαρτώνται μόνα τους, ώστε ένα κλικ στο Grafana να σας πηγαίνει από τον καταρράκτη trace κατευθείαν στην ακατέργαστη εγγραφή.

Τα attributes που αξίζει να ορίζετε σε κάθε gen_ai span:

from opentelemetry import trace

tracer = trace.get_tracer("ai-sdr")

with tracer.start_as_current_span("chat.completion") as span:
    span.set_attribute("gen_ai.system", "anthropic")
    span.set_attribute("gen_ai.request.model", "claude-sonnet-4-20250514")
    response = client.messages.create(**payload)
    span.set_attribute("gen_ai.usage.input_tokens", response.usage.input_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", response.usage.output_tokens)
    span.set_attribute("gen_ai.response.finish_reasons", [response.stop_reason])
    log.info("llm.request", cost_usd=cost)  # Rule 2 record, trace IDs auto-attached

Κανόνας 5: Αποκρύψτε τα PII πριν από την εγγραφή του Log

Η απόκρυψη PII πρέπει να συμβαίνει πριν γραφτεί η εγγραφή, όχι να καθαρίζεται μετά. Μόλις μια διεύθυνση email βρεθεί στο Loki, βρίσκεται και στα αντίγραφα ασφαλείας του object storage σας και το «το διαγράψαμε αργότερα» δεν είναι απάντηση GDPR. Στη δική μας εγκατάσταση, το Microsoft Presidio τρέχει ως structlog processor και πιάνει το 94% των email και των αριθμών τηλεφώνου πριν φτάσουν στο Loki. Όσα ξεφεύγουν είναι σχεδόν όλα περίεργη μορφοποίηση, που τη διορθώνουμε σε custom recognizers καθώς τα βρίσκουμε.

Όλο το hook είναι δεκαπέντε γραμμές:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

PII_ENTITIES = ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER", "CREDIT_CARD", "IBAN_CODE"]

def redact_pii(text: str) -> str:
    results = analyzer.analyze(text=text, language="en", entities=PII_ENTITIES)
    return anonymizer.anonymize(text=text, analyzer_results=results).text

# In the structlog processor chain, before JSONRenderer:
# event_dict["prompt"] = redact_pii(event_dict["prompt"])

Η απόκρυψη βρίσκεται στο ίδιο επίπεδο του pipeline με τα φίλτρα εισόδου και εξόδου σας και πρέπει να δοκιμάζεται με τον ίδιο τρόπο. Το pipeline guardrail μας αντιμετωπίζει ένα email που διέρρευσε σε log ως αποτυχημένο eval, όχι ως υποσημείωση λειτουργίας.

Κανόνας 6: Δειγματοληψία με εξυπνάδα σε υψηλό όγκο

Κάτω από περίπου 100.000 αιτήματα την ημέρα, καταγράψτε τα πάντα. Πάνω από αυτό, η καταγραφή πλήρους όγκου είναι φόρος αποθήκευσης σε δεδομένα που δεν θα διαβάσετε ποτέ και η δειγματοληψία είναι ο τρόπος να κρατήσετε τις εγγραφές που μετρούν. Η παγίδα: η τυχαία δειγματοληψία είναι η χειρότερη επιλογή για κίνηση LLM, επειδή οι αποτυχίες, οι αρνήσεις και τα αιτήματα των πέντε δολαρίων είναι εξ ορισμού σπάνια, άρα ένα ομοιόμορφο ποσοστό 10% απορρίπτει ακριβώς τα συμβάντα που αποσφαλματώνετε. Δειγματοληπτήστε κατά αποτέλεσμα, όχι με στρίψιμο νομίσματος.

Μια συνηθισμένη εγκατάσταση είναι βασισμένη σε κανόνες στα άκρα (production και enterprise tenants: πάντα καταγραφή) και βασισμένη στην ουρά στη μέση. Η γωνία των logs σε αυτό το πλαίσιο: τα πεδία σας guardrail_result και cost_usd είναι τα σήματα δειγματοληψίας, ήδη παρόντα αν ακολουθήσατε τους Κανόνες 2 και 8.

Κανόνας 7: Ορίστε πολιτική διατήρησης πριν τη χρειαστείτε

Μια πολιτική διατήρησης logs είναι απόφαση που παίρνετε όσο είστε ήρεμοι, επειδή η εναλλακτική είναι να την πάρετε κατά τη διάρκεια μιας αναθεώρησης κόστους με διπλάσιο όγκο. Η αρχή περιορισμού αποθήκευσης του άρθρου 5 του GDPR λέει ότι τα προσωπικά δεδομένα πρέπει να διατηρούνται «όχι περισσότερο από όσο είναι αναγκαίο», που στην πράξη σημαίνει διαβάθμιση διατήρησης:

Το hot απαντά γρήγορα και ακριβά στο «τι έγινε πριν δέκα λεπτά;». Το cold απαντά αργά και φθηνά στο «τι είπαμε σε αυτόν τον πελάτη τον Μάρτιο;». Διαγράψτε με πρόγραμμα, αυτόματα, αλλιώς τα επίπεδα είναι απλώς ένα διάγραμμα.

Κανόνας 8: Καταγράψτε τα συμβάντα Guardrail και ασφαλείας ξεχωριστά

Τα συμβάντα ασφαλείας (μπλοκαρίσματα guardrail, αρνήσεις, παραβιάσεις πολιτικής) δεν είναι τηλεμετρία. Είναι εγγραφές ελέγχου και ανήκουν στο δικό τους stream. Τρεις λόγοι. Ειδοποιήσεις: μια έξαρση σε μπλοκαρισμένα prompt injections πρέπει να ειδοποιήσει κάποιον και δεν μπορείτε να συντονίσετε αυτή την ειδοποίηση απέναντι σε 1 εκατ. συνηθισμένες γραμμές. Διατήρηση: η συμμόρφωση μπορεί να απαιτεί τα αρχεία ασφαλείας να επιζούν των debug logs κατά χρόνια. Πρόσβαση: οι ελεγκτές παίρνουν το stream ασφαλείας, όχι όλο σας το firehose. Επισημάνετε την ετυμηγορία στην κύρια εγγραφή (guardrail_result: "block") και δρομολογήστε την πλήρη εγγραφή στο ξεχωριστό stream. Το τι μετράει ως συμβάν ασφαλείας καλύπτεται στον οδηγό μας για τα συμβάντα guardrail.

Κανόνας 9: Κάντε τα Logs ερωτήσιμα, όχι απλώς αποθηκευμένα

Ένα log που δεν μπορείτε να ρωτήσετε σε λιγότερο από ένα λεπτό είναι αντίγραφο ασφαλείας, όχι σήμα παρατηρησιμότητας. Ερωτήσιμο σημαίνει ευρετηριασμένα πεδία, μια γλώσσα ερωτημάτων που ο on-call σας πραγματικά ξέρει και dashboards φτιαγμένα πριν από το περιστατικό. Τρέχουμε Loki και το ρωτάμε 30+ φορές την εβδομάδα για ανωμαλίες κόστους, υποχωρήσεις latency και «δείξε μου κάθε άρνηση για τον tenant X χθες». Τα docs του Grafana Loki είναι η αναφορά για τη σύνταξη. Το μοτίβο που αξίζει τον κόπο είναι το φιλτράρισμα απευθείας σε παρσαρισμένα πεδία JSON:

{service="ai-sdr"} |= "llm.request" | json
  | model = "claude-sonnet-4-20250514"
  | cost_usd > 0.05
  | line_format "{{.timestamp}} {{.request_id}} ${{.cost_usd}} {{.latency_ms}}ms"

Πέντε γραμμές, χωρίς εξαγωγή σε notebook. Αν το τρέχον αποθετήριό σας δεν μπορεί να το κάνει αυτό, είναι το πρόβλημα που πρέπει να διορθώσετε πρώτα.

Τι καταγράφουμε πραγματικά στην παραγωγή

Αρκετά με τη θεωρία. Αυτή είναι η απογυμνωμένη διαμόρφωση από το AI SDR pipeline μας, η υπηρεσία πίσω από τον αριθμό των 1,2 εκατ. αιτημάτων τον μήνα στην εισαγωγή. Τρέχει structlog 25.4.0 που αποδίδει JSON και αποστέλλεται στο Grafana Cloud Loki μέσω Promtail. Το μοντέλο σε αυτό το pipeline είναι το claude-sonnet-4-20250514 και κάθε κλήση περνά ακριβώς από την αλυσίδα processor των Κανόνων 2 και 5:

import structlog

structlog.configure(
    processors=[
        structlog.contextvars.merge_contextvars,
        structlog.processors.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        redact_pii,          # Rule 5: Presidio, before serialization
        add_otel_trace_ids,  # Rule 4: trace_id + span_id from the active span
        structlog.processors.JSONRenderer(),
    ],
)
log = structlog.get_logger()

Δύο νούμερα από το πρώτο τρίμηνο με αυτή την εγκατάσταση. Η μηνιαία εισαγωγή σταθεροποιήθηκε στα 47GB σε τέσσερις υπηρεσίες και το p95 latency εγγραφής log είναι 3ms, που σημαίνει ότι το pipeline δεν προσθέτει τίποτα μετρήσιμο στον χρόνο αιτήματος.

Η αλλαγή διαμόρφωσης που απέσβεσε το κόστος της: προσθέσαμε το cost_usd σε κάθε εγγραφή log τον Μάρτιο του 2026. Μέσα σε μια εβδομάδα βρήκαμε ένα prompt template που έκαιγε 340 $/μήνα σε βρόχους επαναλήψεων. Ένα παροδικό σφάλμα API προκαλούσε τρεις επαναλήψεις, καθεμία από τις οποίες ξαναστελνόταν το πλήρες context των 4.000 tokens. Τα logs το έκαναν ερώτημα μιας γραμμής. Χωρίς κόστος ανά αίτημα, θα εμφανιζόταν ως ανεξήγητη γραμμή στην επόμενη τριμηνιαία αναθεώρηση προϋπολογισμού.

Πόσο κοστίζει η αποθήκευση LLM Log σε κλίμακα;

Σε 1 εκατομμύρια αιτήματα την ημέρα, η αποθήκευση LLM log κοστίζει περίπου 1,20 έως 108 $ τον μήνα για τα ίδια δεδομένα, ανάλογα με το αποθετήριο. Τα μαθηματικά: μια πλήρης δομημένη εγγραφή είναι κατά μέσο όρο περίπου 2KB, άρα 1 εκατ. αιτήματα την ημέρα είναι 2GB την ημέρα ή 60GB τον μήνα. Οι παρακάτω τιμές που δημοσιεύουν οι πωλητές (Ιούλιος 2026) είναι το κόστος αυτών των 60GB σε τρία συνηθισμένα backends.

Πηγές: τιμολόγηση Datadog, Grafana Loki και τα docs παρατηρησιμότητας του ClickHouse.

Δύο επισημάνσεις, επειδή αυτός είναι δικός μας υπολογισμός από τιμές πωλητών, όχι benchmark που τρέξαμε. Πρώτον, το νούμερο του Datadog υποθέτει ότι ευρετηριάζετε τα πάντα. Οι περισσότερες ομάδες ευρετηριάζουν ένα υποσύνολο και πληρώνουν πολύ λιγότερα, ενώ το Loki και το ClickHouse χρεώνουν κυρίως για ό,τι αποθηκεύετε. Δεύτερον, τα 1,20 $ του self-hosted ClickHouse κρύβουν έναν πραγματικό λογαριασμό: το compute για να τρέξει το cluster και τις ώρες μηχανικού για να το λειτουργήσετε. Στα 60GB τον μήνα, μια managed υπηρεσία είναι σχεδόν πάντα η φθηνότερη συνολική απάντηση. Το self-hosting αρχίζει να βγάζει νόημα πάνω από περίπου 1TB τον μήνα, όπου η διαφορά ανά GB υπερκαλύπτει το λειτουργικό κόστος.

Η διασπορά είναι το συμπέρασμα. Σε 1 εκατ. αιτήματα την ημέρα, το χάσμα μεταξύ Datadog με ευρετηρίαση και self-hosted ClickHouse είναι περίπου 90 φορές: 108 $ έναντι 1,20 $ για τα ίδια 60GB. Διαλέξτε το αποθετήριο κατά τον σχεδιασμό της αρχιτεκτονικής, όχι αφού φτάσει ο λογαριασμός.

Ποιο εργαλείο Logging να διαλέξετε;

Για τις περισσότερες ομάδες η επιλογή καταλήγει σε τέσσερις επιλογές: μια πλατφόρμα ειδική για LLM (Langfuse ή LangSmith), ένα εργαλείο επιπέδου proxy (Helicone) ή ένα απλό pipeline OpenTelemetry σε υποδομή που ήδη τρέχετε. Ο πίνακας καλύπτει τα σημεία απόφασης που πραγματικά διαφέρουν. Τα dashboards, η αναπαραγωγή και η εκδοχοποίηση prompt είναι αυτονόητα και στα τέσσερα.

Η γνώμη μας, καθαρά: τρέχουμε OTel-native με Loki επειδή ήδη είχαμε το stack Grafana για όλα τα υπόλοιπα και η προσθήκη μιας ακόμα πηγής δεδομένων νίκησε την υιοθέτηση τέταρτου πωλητή. Αν ξεκινάτε από το μηδέν χωρίς καθόλου stack παρατηρησιμότητας, το μοντέλο tracing του Langfuse και το δωρεάν επίπεδό του είναι ο γρηγορότερος δρόμος προς κάτι χρήσιμο και η επιλογή self-host κρατά ανοιχτή την πόρτα εξόδου. Αν διαλέγετε μεταξύ των δύο ηγετών που είναι ειδικοί σε LLM, η ανάλυσή μας Langfuse εναντίον LangSmith κάνει την πλήρη σύγκριση. Και αν η καταγραφή είναι ένα κομμάτι μιας μεγαλύτερης απόφασης παρακολούθησης, η πλήρης σύγκριση πλατφορμών καλύπτει το ευρύτερο πεδίο.

Ποια είναι τα πιο συνηθισμένα λάθη στο LLM Logging;

Έξι λάθη ευθύνονται για τα περισσότερα χαλασμένα setup LLM logging που έχουμε δει. Το καθένα είναι φθηνό να αποφευχθεί αν το πιάσετε πριν το κάνει ο όγκος των logs:

• Καταγραφή ωμών PII χωρίς απόκρυψη. Το πιο συνηθισμένο και το πιο ακριβό. Μια εξαγωγή υποστήριξης ή ένα παραβιασμένο bucket μετατρέπει τα prompt logs σε περιστατικό προστασίας δεδομένων. Αποκρύψτε πριν από την εγγραφή (Κανόνας 5), όχι κατά την ανάγνωση.
• Καμία πολιτική διατήρησης. Η αποθήκευση επ' αόριστον είναι η προεπιλογή παντού και διπλασιάζει σιωπηλά τον λογαριασμό σας κάθε χρόνο. Αν δεν διαγράφετε ποτέ, δεν έχετε σύστημα καταγραφής. Έχετε ένα αρχείο με μεγαλομανία.
• Logs ελεύθερου κειμένου. Η έξοδος print που μπορείτε μόνο να κάνετε grep δουλεύει σε κλίμακα demo και καταρρέει στα 100.000 αιτήματα την ημέρα, όταν το «βρες κάθε αποτυχημένο αίτημα για το μοντέλο Χ» γίνεται απόγευμα με shell scripts αντί για ερώτημα.
• Καταγραφή μόνο σφαλμάτων. Τα επιτυχημένα αιτήματα είναι η γραμμή βάσης απέναντι στην οποία ανιχνεύετε απόκλιση και είναι η πρώτη ύλη του pipeline αξιολόγησής σας. Καταγράψτε και τις επιτυχίες, με δειγματοληψία αν ο όγκος το επιβάλλει.
• Αγνόηση πεδίων κόστους. Χωρίς cost_usd ανά αίτημα δεν έχετε ειδοποιήσεις κόστους, καμία απόδοση ανά feature και ο βρόχος επαναλήψεων των 340 $/μήνα από την ενότητα παραγωγής παραπάνω μένει αόρατος μέχρι τον τριμηνιαίο λογαριασμό.
• Χωρίς συσχέτιση trace. Τα logs αποκομμένα από τα spans κάνουν την αποσφαλμάτωση agent πολλαπλών βημάτων εικασία. Αν στη γραμμή log σας λείπει το trace_id, ο Κανόνας 4 είναι η λύση.

Σχετικά με τον συγγραφέα

Ο Mert Batur είναι συνιδρυτής της Techsy.io, όπου η ομάδα παραδίδει AI agents, συστήματα αυτοματισμού και pipelines φωνής/SDR για B2B πελάτες. Γράφει για το stack εργαλείων LLM που η ομάδα της Techsy χρησιμοποιεί πραγματικά στην παραγωγή. Συνδεθείτε στο LinkedIn.

Συχνές ερωτήσεις

Τι πρέπει να καταγράφετε για κάθε LLM αίτημα;

Το ελάχιστο: το πλήρες prompt και την ολοκλήρωση με αποκρυμμένα PII, το όνομα του μοντέλου, τον αριθμό tokens εισόδου και εξόδου, τον χρόνο απόκρισης, το κόστος σε USD, ένα κατακερματισμένο αναγνωριστικό χρήστη και τα trace και span IDs του OpenTelemetry. Προσθέστε αναγνωριστικά πηγών RAG και την ετυμηγορία του guardrail αν το pipeline σας έχει αυτά τα στάδια. Δεκατέσσερα ονοματισμένα πεδία, μία γραμμή JSON ανά αίτημα.

Ποια είναι η καλύτερη μορφή για LLM logs;

Δομημένο JSON, ένα αντικείμενο ανά αίτημα, με κάθε πεδίο ρητά ονοματισμένο. Τα logs ελεύθερου κειμένου μπορούν μόνο να γίνουν grep. Οι εγγραφές JSON μπορούν να συγκεντρωθούν ανά μοντέλο, να αθροιστούν ανά κόστος και να ενωθούν με traces. Εκπέμψτε την εγγραφή με δομημένο logger όπως το structlog σε Python ή το pino σε Node και αποδώστε την με serializer JSON, ποτέ με string formatting.

Πώς διαχειρίζεστε τα PII στα LLM logs;

Αποκρύψτε πριν από την εγγραφή του log, όχι μετά. Περάστε το prompt και την ολοκλήρωση από έναν ανιχνευτή όπως το Microsoft Presidio μέσα στο logging pipeline σας, αντικαθιστώντας ονόματα, email και αριθμούς τηλεφώνου με tokens όπως <EMAIL_ADDRESS>. Μόλις ωμά PII φτάσουν στο αποθετήριο logs σας, βρίσκονται και στα αντίγραφα ασφαλείας σας και η εκ των υστέρων διαγραφή σπάνια ικανοποιεί το τεστ ελαχιστοποίησης του GDPR.

Πόσο κοστίζει η αποθήκευση LLM log σε κλίμακα;

Για 1 εκατ. αιτήματα την ημέρα, περίπου 60GB τον μήνα στα 2KB ανά εγγραφή, υπολογίστε περίπου 108 $/μήνα στην τιμολόγηση LLM Observability του Datadog με ευρετηρίαση, 30 $/μήνα στο Grafana Cloud Loki ή περίπου 1,20 $/μήνα σε συμπιεσμένη αποθήκευση S3 για self-hosted ClickHouse συν compute. Αυτές είναι τιμές δημοσιευμένες από πωλητές από τον Ιούλιο του 2026. Το self-hosting προσθέτει χρόνο μηχανικού από πάνω.

Τι είναι οι σημασιολογικές συμβάσεις GenAI του OpenTelemetry;

Είναι τα τυπικά ονόματα attributes του OpenTelemetry για την οργάνωση κλήσεων LLM: gen_ai.system για τον πάροχο, gen_ai.request.model για το μοντέλο, gen_ai.usage.input_tokens και output_tokens για τον αριθμό tokens και gen_ai.response.finish_reasons για το γιατί σταμάτησε η παραγωγή. Η χρήση τους σημαίνει ότι οποιοδήποτε backend συμβατό με OTel, από το Jaeger στο Tempo στο Langfuse, διαβάζει τα traces σας χωρίς custom parsers.

Πώς κάνετε δειγματοληψία LLM logs σε υψηλή κίνηση;

Κρατήστε κάθε σφάλμα, κάθε μπλοκάρισμα guardrail και κάθε αίτημα πάνω από ένα κατώφλι κόστους και μετά δειγματοληπτήστε τα υπόλοιπα. Αυτή η προσέγγιση ουράς διατηρεί τα σπάνια συμβάντα που πραγματικά αποσφαλματώνετε, ενώ η ομοιόμορφη τυχαία δειγματοληψία τα απορρίπτει με τον ίδιο ρυθμό όπως την ανιαρή κίνηση. Κάτω από 100.000 αιτήματα την ημέρα, παραλείψτε εντελώς τη δειγματοληψία και καταγράψτε τα πάντα.

Πόσο καιρό πρέπει να διατηρείτε τα LLM logs;

Διαβαθμίστε τα: 7 ημέρες hot για ζωντανή αποσφαλμάτωση, 30 ημέρες warm για αναθεώρηση περιστατικών και ανάλυση κόστους και έως 1 έτος cold σε συμπιεσμένο object storage για συμμόρφωση και ελέγχους. Η αρχή περιορισμού αποθήκευσης του GDPR απαγορεύει τη διατήρηση προσωπικών δεδομένων περισσότερο από όσο είναι αναγκαίο, άρα συνδυάστε κάθε επίπεδο με αυτόματη διαγραφή αντί για χειροκίνητο καθαρισμό.

Ποια είναι η διαφορά μεταξύ LLM logging και LLM tracing;

Ένα log είναι μια επίπεδη εγγραφή ενός συμβάντος: αυτό το αίτημα συνέβη, με αυτά τα πεδία. Ένα trace είναι ένα αιτιώδες δέντρο spans σε ολόκληρη τη διαδρομή ενός αιτήματος, ας πούμε ανάκτηση, μετά η κλήση μοντέλου, μετά δύο κλήσεις εργαλείων. Τα logs σάς λένε τι. Τα traces σάς λένε πού και γιατί. Τα setup παραγωγής εκπέμπουν και τα δύο, ενωμένα με το trace_id.

Συμπέρασμα

Ανακεφαλαίωση: καταγράψτε κάθε αίτημα ως JSON με ονοματισμένα πεδία, υπολογίστε το κόστος τη στιγμή του αιτήματος, προσαρτήστε trace context OTel, αποκρύψτε τα PII πριν από την εγγραφή, δειγματοληπτήστε κατά αποτέλεσμα μόλις ξεπεράσετε τα 100.000 αιτήματα την ημέρα και διαλέξτε ένα αποθετήριο που πραγματικά μπορείτε να ρωτήσετε. Οι εννέα κανόνες είναι ταξινομημένοι ώστε να μπορείτε να υιοθετήσετε έναν ανά sprint και οι Κανόνες 2, 4 και 5 είναι οι τρεις που αποδίδουν γρηγορότερα. Αν διαλέγετε το ευρύτερο stack παρακολούθησης γύρω από τα logs, ξεκινήστε με τη συλλογή μας για τις καλύτερες πλατφόρμες παρατηρησιμότητας AI. Και αν χρειάζεστε βοήθεια για να στήσετε δομημένη καταγραφή για το LLM stack σας, πάρτε μια δωρεάν συμβουλευτική.