MetaTrader 5 / Beispiele
English Русский 中文 日本語
preview
Meistern der Log-Einträge (Teil 1): Grundlegende Konzepte und erste Schritte in MQL5

Meistern der Log-Einträge (Teil 1): Grundlegende Konzepte und erste Schritte in MQL5

MetaTrader 5 — Beispiele |
116 0
joaopedrodev
joaopedrodev

Einführung

Willkommen zum Beginn einer neuen Reise! Dieser Artikel eröffnet eine spezielle Serie, in der wir Schritt für Schritt eine Bibliothek für den Umgang mit Protokollen erstellen werden, die auf diejenigen zugeschnitten ist, die in der Sprache MQL5 entwickeln. Die Idee ist einfach, aber ehrgeizig: ein robustes, flexibles und hochwertiges Hilfsmittel anzubieten, das die Aufzeichnung und Analyse von Logs in Expert Advisors (EAs) praktischer, effizienter und leistungsfähiger macht.

Heute gibt es eigene Logs im die MetaTrader 5, die ihre grundlegenden Aufgabe der Überwachung erfüllen: Terminalstart, Serververbindungen, Umgebungsdetails. Aber seien wir ehrlich, diese Protokolle wurden nicht für die Besonderheiten der Entwicklung von EAs konzipiert. Wenn wir das spezifische Verhalten eines EA bei der Ausführung verstehen wollen, stoßen wir an Grenzen. Es mangelt an Präzision, Kontrolle und der individuellen Anpassung, die den Unterschied ausmacht.

Genau hier setzt der Vorschlag dieser Reihe an: weiter zu gehen. Wir bauen ein maßgeschneidertes Protokollsystem von Grund auf, das vollständig anpassbar ist. Stellen Sie sich vor, Sie hätten die vollständige Kontrolle darüber, was protokolliert werden soll: kritische Ereignisse, Fehlerverfolgung, Leistungsanalyse oder sogar die Speicherung bestimmter Informationen für zukünftige Untersuchungen. All dies natürlich auf organisierte Weise und mit der Effizienz, die das Szenario erfordert.

Aber es geht nicht nur um Code. Diese Serie geht über die Tastatur hinaus. Wir werden die Grundlagen der Protokollierung erforschen, das „Warum“ vor dem „Wie“ verstehen, bewährte Entwurfspraktiken diskutieren und gemeinsam etwas entwickeln, das nicht nur funktional, sondern auch elegant und intuitiv ist. Schließlich geht es bei der Entwicklung von Software nicht nur um die Lösung von Problemen, sondern auch um eine Kunst.



Was sind Protokolle bzw. Logs?

Funktionell gesehen sind Protokolle chronologische Aufzeichnungen von Ereignissen, die Systeme und Anwendungen ständig erzeugen. Sie sind wie Augenzeugenberichte über jeden Antrag, jeden Fehler und jede Entscheidung, die der Fachberater getroffen hat. Wenn ein Entwickler herausfinden will, warum ein Ablauf nicht funktioniert, sind die Protokolle sein Ausgangspunkt. Ohne sie wäre die Interpretation des Geschehens gleichbedeutend mit der Erkundung eines Labyrinths im Dunkeln.

Die Wahrheit ist, dass wir zunehmend von einem digitalen Universum umgeben sind, in dem Systeme nicht mehr nur Werkzeuge sind, sondern wichtige Zahnräder in einer Welt, die Code atmet. Denken Sie an sofortige Kommunikation, Finanztransaktionen im Bruchteil einer Sekunde oder die automatische Steuerung einer Industrieanlage. Verlässlichkeit ist hier kein Luxus, sondern eine Voraussetzung. Aber... was passiert, wenn etwas schief geht? Wo beginnt die Suche nach dem, was kaputt gegangen ist? Protokolle sind die Antwort. Sie sind die Augen und Ohren innerhalb der Blackbox, die wir Systeme nennen.

Stellen Sie sich Folgendes vor: Ein Expert Advisor beginnt bei einer automatisierten Verhandlung mit einer fehlschlagenden Massenanfragen an den Server. Plötzlich tauchen Absagen auf. Ohne strukturierte Protokolle kann man nur Hypothesen aufstellen: Ist der Server überlastet? Vielleicht ist die Konfiguration eines Expertenberaters falsch? Mit gut gestalteten Protokollen können Sie nicht nur den „Heuhaufen“ finden, sondern auch die genaue Nadel, einen Authentifizierungsfehler, eine Zeitüberschreitung oder sogar ein übermäßiges Anfragevolumen.

Aber nicht alles ist perfekt in den Protokollen. Wenn man sie ohne Kriterien einsetzt, kann man sich selbst ins Knie schießen: irrelevante Daten sammeln sich an, der Speicheraufwand explodiert und im schlimmsten Fall können sensible Informationen nach außen dringen. Außerdem reicht es nicht aus, über Protokolle zu verfügen; man muss wissen, wie man sie klar konfiguriert und genau interpretiert. Andernfalls wird das, was eine Landkarte sein sollte, zu einem chaotischen Rauschen, das mehr Verwirrung stiftet als eine Lösung.

Wenn man sich die Protokolle genauer ansieht, versteht man, dass sie nicht nur Werkzeuge sind. Sie sind stille Partner, die zum richtigen Zeitpunkt zeigen, was die Systeme zu sagen haben. Und wie in jeder guten Partnerschaft liegt der Wert darin, dass man weiß, wie man zuhört.

Etwas praktischer ausgedrückt, bestehen Protokolle aus Textzeilen, die bestimmte Ereignisse innerhalb eines Systems dokumentieren. Sie können Informationen wie z. B. enthalten:

  • Datum und Uhrzeit des Ereignisses: um festzustellen, wann etwas passiert ist.
  • Ereignistyp: Fehler, Warnung, Information, Debug und andere.
  • Beschreibende Nachricht: Erklärung des Geschehens.
  • Zusätzlicher Kontext: technische Details, wie z. B. Variablenwerte zum Zeitpunkt, Daten zum Diagramm, wie z. B. Zeitrahmen oder Symbol, oder sogar einige Werte eines verwendeten Parameters.



Vorteile der Verwendung von Protokollen bzw. Logs

Im Folgenden werden einige der wichtigsten Vorteile des Einsatzes von Protokollen erläutert und aufgezeigt, wie diese die Abläufe optimieren und die Effizienz von Expertenberatern gewährleisten können.

1.Fehlersuche und Fehlerbehebung

Mit gut strukturierten Protokollen ändert sich alles. Sie geben nicht nur Aufschluss darüber, was schief gelaufen ist, sondern auch über das Warum und das Wie. Ein Fehler, der zuvor wie ein flüchtiger Schatten erschien, wird zu etwas, das man verfolgen, verstehen und korrigieren kann. Es ist wie ein Vergrößerungsglas, das jedes kritische Detail des Moments vergrößert, in dem das Problem aufgetreten ist.

Stellen Sie sich zum Beispiel vor, dass eine Anfrage unerwartet fehlschlägt. Ohne Protokolle könnte das Problem dem Zufall zugeschrieben werden, und die Lösung bliebe dem Rätselraten überlassen. Doch mit klaren Protokollen ändert sich das Szenario. Die Fehlermeldung erscheint als Leuchtfeuer, begleitet von wertvollen Daten über die betreffende Anfrage: gesendete Parameter, Serverantwort oder sogar eine unerwartete Zeitüberschreitung. Dieser Zusammenhang offenbart nicht nur den Ursprung des Fehlers, sondern zeigt auch den Weg zur Lösung des Problems auf.

Praktisches Beispiel für ein Fehlerprotokoll:

[2024-11-18 14:32:15] ERROR : Limit Buy Trade Request Failed - Invalid Price in Request [10015 | TRADE_RETCODE_INVALID_PRICE]

Aus diesem Protokoll geht genau hervor, was der Fehler war, nämlich der Versuch, eine Anfrage an den Server zu senden, und dass der Fehlercode 10015 war, was einen ungültigen Preisfehler in der Anfrage darstellt, sodass der Entwickler des Expertenberaters genau weiß, in welcher Reihenfolge der Fehler auftritt, in diesem Beispiel beim Senden einer Limit-Kauforderung.

2.Auditing und Compliance

Protokolle spielen eine wichtige Rolle, wenn es um die Überprüfung (Auditing) und Einhaltung (Compliance) von Sicherheitsstandards und -richtlinien geht. In Sektoren, die mit sensiblen Daten umgehen, wie z. B. im Finanzwesen, geht die Forderung nach detaillierten Aufzeichnungen über die reine Organisation hinaus: Es geht darum, sich an die für den Betrieb geltenden Gesetze und Vorschriften zu halten.

Sie dienen als verlässliche Spur, die jede relevante Aktion dokumentiert: wer hat wann auf die Informationen zugegriffen und was wurde getan. Dies bringt nicht nur Transparenz in die Umgebung, sondern wird auch zu einem leistungsfähigen Instrument bei der Untersuchung von Sicherheitsvorfällen oder fragwürdigen Praktiken. Mit gut strukturierten Protokollen ist die Identifizierung unregelmäßiger Aktivitäten keine nebulöse Herausforderung mehr, sondern wird zu einem direkten und effizienten Prozess, der das Vertrauen und die Sicherheit im System stärkt.

3.Leistungsüberwachung

Die Verwendung von Protokollen ist auch für die Leistungsüberwachung von Systemen von entscheidender Bedeutung. In Produktionsumgebungen, in denen Reaktionszeit und Effizienz entscheidend sind, können Sie mit Hilfe von Protokollen den Zustand Ihres Expertenberaters in Echtzeit verfolgen. Leistungsprotokolle können Informationen über die Antwortzeit von Aufträgen, die Ressourcennutzung (z. B. CPU, Speicher und Festplatte) und Fehlerraten enthalten. Von dort aus können Korrekturmaßnahmen ergriffen werden, wie z. B. die Optimierung des Codes.

Beispiel für ein Leistungsprotokoll:

[2024-11-18 16:45:23] INFO - Server response received, EURUSD purchase executed successfully | Volume: 0.01 | Price: 1.01234 | Duration: 49 ms

4. Automatisierung und Warnungen

Die Automatisierung ist einer der großen Vorteile von Protokollen, insbesondere wenn sie in Überwachungs- und Analysetools integriert sind. Mit der richtigen Konfiguration können die Protokolle automatische Warnungen auslösen, sobald kritische Ereignisse erkannt werden. So wird sichergestellt, dass der Entwickler sofort über Ausfälle, Fehler oder sogar größere Verluste informiert wird, die durch den Expert Advisor generiert werden.

Diese Warnungen gehen über einfache Warnungen hinaus: Sie können per E-Mail oder SMS verschickt oder in Managementplattformen integriert werden und ermöglichen eine schnelle und präzise Reaktion. Dieser Automatisierungsgrad schützt das System nicht nur vor Problemen, die schnell eskalieren können, sondern gibt dem Entwickler auch die Möglichkeit, proaktiv zu handeln, um die Auswirkungen zu minimieren und die Stabilität der Umgebung zu gewährleisten.

Beispiel für ein Protokoll mit einer Warnung:

[2024-11-18 19:15:50] FATAL - CPU usage exceeded 90%, immediate attention required.

Kurz gesagt, die Vorteile der Verwendung von Protokollen gehen weit über die einfache Aufzeichnung von Informationen über die Vorgänge in Ihrem Expert Advisor hinaus. Sie bieten ein leistungsfähiges Tool für Debugging, Leistungsüberwachung, Sicherheitsaudits und Alarmautomatisierung und sind damit eine unverzichtbare Komponente für die effiziente Verwaltung der Infrastruktur Ihrer Experten.



Definition der Bibliotheksanforderungen

Bevor wir mit der Entwicklung beginnen, ist es wichtig, eine klare Vorstellung davon zu haben, was wir erreichen wollen. Auf diese Weise vermeiden wir Überarbeitungen und stellen sicher, dass die Bibliothek den tatsächlichen Bedürfnissen der Nutzer entspricht. In diesem Sinne habe ich die wichtigsten Funktionen aufgelistet, die diese Bibliothek für die Protokollverarbeitung bieten sollte:

  1. Singleton

    Die Bibliothek sollte das Designmuster Singleton implementieren, um sicherzustellen, dass alle Instanzen auf dasselbe Protokollobjekt zugreifen. Dadurch wird die Konsistenz der Protokollverwaltung in den verschiedenen Teilen des Codes gewährleistet und eine unnötige Duplizierung von Ressourcen vermieden. Im nächsten Artikel werde ich darauf näher eingehen.

  2. Datenbank-Speicher

    Ich möchte, dass alle Protokolle in einer Datenbank gespeichert werden, um Abfragen auf die Daten zu ermöglichen. Dies ist eine wichtige Funktion für die Analyse der Historie, für Audits und sogar für die Identifizierung von Verhaltensmustern.

  3. Verschiedene Ausgaben

    Die Bibliothek sollte die Möglichkeit bieten, Protokolle auf verschiedene Arten anzuzeigen, z. B:

    • Konsole
    • Terminal
    • Dateien
    • Datenbank

    Diese Vielfalt ermöglicht den Zugriff auf die Protokolle in dem für die jeweilige Situation am besten geeigneten Format.

  4. Log-Stufen

    Wir sollten verschiedene Protokollierungsebenen unterstützen, um Meldungen nach ihrem Schweregrad zu klassifizieren. Die Stufen umfassen:

    • DEBUG : Detaillierte Meldungen zur Fehlersuche.
    • INFO : Allgemeine Informationen über den Betrieb des Systems.
    • ALERT : Warnungen für Situationen, die Aufmerksamkeit erfordern, aber nicht kritisch sind.
    • ERROR : Fehler, die Teile des Systems betreffen, aber die Kontinuität ermöglichen.
    • FATAL : Schwerwiegende Probleme, die die Ausführung des Systems unterbrechen.

  1. Nutzerdefiniertes Protokollformat

    Es ist wichtig, dass das Format der Protokollmeldungen angepasst werden kann. Ein Beispiel wäre:

    ([{timestamp}] {level} : {origin} {message})

    Dies ermöglicht eine flexible Anpassung der Ergebnisse an die spezifischen Bedürfnisse jedes Projekts.

  2. Rotierendes Log

    Um ein unkontrolliertes Wachstum der Protokolldateien zu vermeiden, sollte die Bibliothek ein Rotationssystem einführen, bei dem die Protokolle jeden Tag oder nach Erreichen einer bestimmten Größe in anderen Dateien gespeichert werden.

  3. Dynamische Datenspalten

    Ein wesentliches Merkmal ist die Möglichkeit, dynamische Metadaten im JSON-Format zu speichern. Diese Daten können Informationen enthalten, die für den Expert Advisor zum Zeitpunkt der Aufzeichnung der Meldung spezifisch sind und den Kontext der Protokolle bereichern.

  4. Automatische Benachrichtigungen

    Die Bibliothek sollte in der Lage sein, Benachrichtigungen in bestimmten Schweregraden zu senden, z. B. FATAL . Diese Warnungen können per E-Mail gesendet werden:

    • E-Mail
    • SMS
    • Terminal-Warnungen

    Auf diese Weise wird sichergestellt, dass die zuständigen Stellen sofort über kritische Probleme informiert werden.

  5. Längenmessung des Codes

    Schließlich ist es wichtig, eine Funktion zur Messung der Länge von Codeabschnitts aufzunehmen. So können wir Leistungsengpässe erkennen und Prozesse optimieren.

Diese Anforderungen werden die Grundlage für die Entwicklung dieser Bibliothek bilden. Im weiteren Verlauf der Implementierung werden wir untersuchen, wie die einzelnen Funktionen aufgebaut und in das Ganze integriert werden. Dieser strukturierte Ansatz hilft uns nicht nur dabei, konzentriert zu bleiben, sondern stellt auch sicher, dass das Endprodukt robust, flexibel und an die Bedürfnisse von Expert Advisor-Entwicklern in der MQL5-Umgebung anpassbar ist.



Strukturierung der Projektbasis

Nachdem wir nun die Anforderungen genau definiert haben, müssen wir als Nächstes mit der Strukturierung der Basis unseres Projekts beginnen. Die korrekte Organisation von Dateien und Ordnern ist entscheidend dafür, dass der Code modular, leicht verständlich und wartbar bleibt. Beginnen wir also damit, die anfängliche Struktur der Verzeichnisse und Dateien für unsere Protokollbibliothek zu erstellen.

Der erste Schritt besteht darin, einen neuen Ordner innerhalb des Includes-Ordners zu erstellen, in dem alle Dateien der Protokollbibliothek gespeichert werden sollen. Klicken Sie dazu einfach mit der rechten Maustaste auf den Ordner „Includes“ in der Navigationsleiste, wie in der Abbildung gezeigt, und wählen Sie die Option „Neuer Ordner“:

Danach werden wir diesen Ordner „Logify“ nennen. Dann erstellen wir die erste und wichtigste Datei der Bibliothek, indem wir mit der rechten Maustaste auf den Ordner klicken und die Option „Neue Datei“ wählen.

Es erscheint ein Fenster mit den Optionen für die neue Datei, wählen Sie die Option „Neue Klasse“ und drücken Sie auf „Weiter“, dann sehen Sie dieses Fenster:

Füllen Sie die Parameter aus, der Klassenname wird CLogify sein, danach habe ich den Autorennamen und den Link geändert, aber diese Parameter sind für die Klasse nicht relevant. Am Ende wird es so aussehen:

Drücken Sie auf „Fertigstellen“, um die neue Datei zu erstellen. Der vollständige Pfad zur Hauptbibliotheksdatei lautet dann: <Include/Logify/Logify.mqh>. Der Code der Datei sieht wie folgt aus: 
//+------------------------------------------------------------------+
//|                                                       Logify.mqh |
//|                                                     joaopedrodev |
//|                       https://www.mql5.com/en/users/joaopedrodev |
//+------------------------------------------------------------------+
#property copyright "joaopedrodev"
#property link      "https://www.mql5.com/en/users/joaopedrodev"
#property version   "1.00"
class CLogify
  {
private:

public:
                     CLogify();
                    ~CLogify();
  };
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
CLogify::CLogify()
  {
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
CLogify::~CLogify()
  {
  }
//+------------------------------------------------------------------+

Erstellen Sie nach dem gleichen Schema zwei weitere Dateien:

  • LogifyLevel.mqh → Definiert ein Enum mit den zu verwendenden Protokollstufen.
  • LogifyModel.mqh → Datenstruktur zum Speichern detaillierter Informationen über jedes Protokoll

Am Ende werden wir diese Ordner- und Dateistruktur haben:

|--- Logify
|--- Logify.mqh
|--- LogifyLevel.mqh
|--- LogifyModel.mqh

Mit der Grundstruktur und den ersten Dateien haben wir ein funktionierendes Skelett der Protokollbibliothek.



Erstellen von Schweregraden

Hier werden wir die Datei LogifyLevel.mqh verwenden. Diese Datei definiert die verschiedenen Schweregrade, die ein Protokoll haben kann, gekapselt in einem Enum. Dies ist der Code der Enumeration, die verwendet werden soll:

enum ENUM_LOG_LEVEL
  {
   LOG_LEVEL_DEBUG = 0,    // Debug
   LOG_LEVEL_INFOR,        // Infor
   LOG_LEVEL_ALERT,        // Alert
   LOG_LEVEL_ERROR,        // Error
   LOG_LEVEL_FATAL,        // Fatal
  };

Erklärung

  • Enumeration: Jeder Wert der Enumeration stellt einen Schweregrad für die Protokolle dar, der von LOG_LEVEL_DEBUG (am wenigsten schwerwiegend) bis LOG_LEVEL_FATAL (am schwerwiegendsten) reicht.
  • Nutzerfreundlichkeit: Diese Enumeration wird verwendet, um die Protokolle in verschiedene Stufen zu kategorisieren, was die Filterung oder spezifische Aktionen auf der Grundlage des Schweregrads erleichtert.



Erstellen des Datenmodells

Lassen Sie uns nun eine Datenstruktur erstellen, um die Protokollinformationen zu speichern, die von der Bibliothek verarbeitet werden. Diese Struktur wird in der Datei LogifyModel.mqh gespeichert und dient als Grundlage für die Speicherung aller vom System erfassten Protokolle.

Nachfolgend finden Sie den Code zur Definition der Struktur MqlLogifyModel , die für die Speicherung der wesentlichen Daten jedes Protokolleintrags zuständig ist, wie z. B. den Zeitstempel (Datum und Uhrzeit des Ereignisses), die Quelle (von der das Protokoll erstellt wurde), die Protokollnachricht und alle zusätzlichen Metadaten.

//+------------------------------------------------------------------+
//|                                                  LogifyModel.mqh |
//|                                                     joaopedrodev |
//|                       https://www.mql5.com/en/users/joaopedrodev |
//+------------------------------------------------------------------+
#property copyright "joaopedrodev"
#property link      "https://www.mql5.com/en/users/joaopedrodev"
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
#include "LogifyLevel.mqh"
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
struct MqlLogifyModel
  {
   ulong timestamp;        // Date and time of the event
   ENUM_LOG_LEVEL level;   // Severity level
   string origin;          // Log source
   string message;         // Log message
   string metadata;        // Additional information in JSON or text
   
   MqlLogifyModel::MqlLogifyModel(void)
     {
      timestamp = 0;
      level = LOG_LEVEL_DEBUG;
      origin = "";
      message = "";
      metadata = "";
     }
   MqlLogifyModel::MqlLogifyModel(ulong _timestamp,ENUM_LOG_LEVEL _level,string _origin,string _message,string _metadata)
     {
      timestamp = _timestamp;
      level = _level;
      origin = _origin;
      message = _message;
      metadata = _metadata;
     }
  };
//+------------------------------------------------------------------+

Erläuterung der Datenstruktur

  • timestamp: Ein ulong-Wert, der das Datum und die Uhrzeit des Ereignisses speichert. Dieses Feld wird mit dem Zeitstempel des Protokolls zum Zeitpunkt der Erstellung des Protokolleintrags ausgefüllt.
  • level: Schweregrad der Meldung
  • origin: Ein Text-Feld, das den Ursprung des Protokolls identifiziert. Dies kann nützlich sein, um festzustellen, welcher Teil des Systems die Protokollmeldung erzeugt hat (z. B. der Name des Moduls oder der Funktion).
  • message: Die eigentliche Protokollmeldung, ebenfalls vom Typ String, die das Ereignis oder die Aktion beschreibt, die im System aufgetreten ist.
  • metadata: Ein zusätzliches Feld, das zusätzliche Informationen über das Protokoll speichert. Dies kann ein JSON-Objekt oder eine einfache Textzeichenfolge sein, die zusätzliche Daten zum Ereignis enthält. Dies ist nützlich, um Kontextinformationen wie Ausführungsparameter oder systemspezifische Daten zu speichern.

Konstrukteure

  • Der Standardkonstruktor initialisiert alle Felder mit leeren Werten oder Null.
  • Der parametrisierte Konstruktor ermöglicht es Ihnen, eine Instanz von MqlLogifyModel zu erstellen, indem Sie die Felder direkt mit bestimmten Werten ausfüllen, z. B. Zeitstempel, Quelle, Nachricht und Metadaten.



Implementieren der Hauptklasse CLogify

Nun werden wir die Hauptklasse der Protokollierungsbibliothek, CLogify, implementieren, die als Kern für die Verwaltung und Anzeige von Protokollen dienen wird. Diese Klasse enthält Methoden für verschiedene Protokollstufen und eine allgemeine Methode namens Append, die von allen anderen Methoden verwendet wird.

Die Klasse wird in der Datei Logify.mqh definiert und enthält die folgenden Methoden:

//+------------------------------------------------------------------+
//| class : CLogify                                                  |
//|                                                                  |
//| [PROPERTY]                                                       |
//| Name        : Logify                                             |
//| Heritage    : No heritage                                        |
//| Description : Core class for log management.                     |
//|                                                                  |
//+------------------------------------------------------------------+
class CLogify
  {
private:
   
public:
                     CLogify();
                    ~CLogify();
   
   //--- Generic method for adding logs
   bool              Append(ulong timestamp, ENUM_LOG_LEVEL level, string message, string origin = "", string metadata = "");
   
   //--- Specific methods for each log level
   bool              Debug(string message, string origin = "", string metadata = "");
   bool              Infor(string message, string origin = "", string metadata = "");
   bool              Alert(string message, string origin = "", string metadata = "");
   bool              Error(string message, string origin = "", string metadata = "");
   bool              Fatal(string message, string origin = "", string metadata = "");
  };
//+------------------------------------------------------------------+
//| Constructor                                                      |
//+------------------------------------------------------------------+
CLogify::CLogify()
  {
  }
//+------------------------------------------------------------------+
//| Destructor                                                       |
//+------------------------------------------------------------------+
CLogify::~CLogify()
  {
  }
//+------------------------------------------------------------------+
Die Methoden der Klasse werden implementiert, um Protokolle auf der Konsole mit der Funktion Print anzuzeigen. Später können diese Protokolle in andere Ausgabedateien wie Dateien, Datenbanken oder Diagramme geleitet werden. 
//+------------------------------------------------------------------+
//| Generic method for adding logs                                   |
//+------------------------------------------------------------------+
bool CLogify::Append(ulong timestamp,ENUM_LOG_LEVEL level,string message,string origin="",string metadata="")
  {
   MqlLogifyModel model(timestamp,level,origin,message,metadata);
   string levelStr = "";
   switch(level)
     {
      case LOGIFY_DEBUG: levelStr = "DEBUG"; break;
      case LOGIFY_INFO:  levelStr = "INFO";  break;
      case LOGIFY_ALERT: levelStr = "ALERT"; break;
      case LOGIFY_ERROR: levelStr = "ERROR"; break;
      case LOGIFY_FATAL: levelStr = "FATAL"; break;
     }
   
   Print("[" + TimeToString(timestamp) + "] [" + levelStr + "] [" + origin + "] - " + message + " " + metadata);
   return(true);
  }
//+------------------------------------------------------------------+
//| Debug level message                                              |
//+------------------------------------------------------------------+
bool CLogify::Debug(string message,string origin="",string metadata="")
  {
   return(this.Append(TimeCurrent(),LOG_LEVEL_DEBUG,message,origin,metadata));
  }
//+------------------------------------------------------------------+
//| Infor level message                                              |
//+------------------------------------------------------------------+
bool CLogify::Infor(string message,string origin="",string metadata="")
  {
   return(this.Append(TimeCurrent(),LOG_LEVEL_INFOR,message,origin,metadata));
  }
//+------------------------------------------------------------------+
//| Alert level message                                              |
//+------------------------------------------------------------------+
bool CLogify::Alert(string message,string origin="",string metadata="")
  {
   return(this.Append(TimeCurrent(),LOG_LEVEL_ALERT,message,origin,metadata));
  }
//+------------------------------------------------------------------+
//| Error level message                                              |
//+------------------------------------------------------------------+
bool CLogify::Error(string message,string origin="",string metadata="")
  {
   return(this.Append(TimeCurrent(),LOG_LEVEL_ERROR,message,origin,metadata));
  }
//+------------------------------------------------------------------+
//| Fatal level message                                              |
//+------------------------------------------------------------------+
bool CLogify::Fatal(string message,string origin="",string metadata="")
  {
   return(this.Append(TimeCurrent(),LOG_LEVEL_FATAL,message,origin,metadata));
  }
//+------------------------------------------------------------------+

Nachdem wir nun die Hauptstruktur und die Methoden für die Anzeige grundlegender Protokolle kennen, besteht der nächste Schritt darin, Tests zu erstellen, um sicherzustellen, dass sie korrekt funktionieren. Auch hier werden wir später Unterstützung für verschiedene Ausgabetypen wie Dateien, Datenbanken und Diagramme hinzufügen.



Tests

Um Tests mit der Logify-Bibliothek durchzuführen, erstellen wir einen speziellen Expert Advisor. Erstellen Sie zunächst einen neuen Ordner namens Logify im Verzeichnis „Experts“, der alle Testdateien enthalten wird. Erstellen Sie dann die Datei LogifyTest.mq5 mit der ursprünglichen Struktur: 
//+------------------------------------------------------------------+
//|                                                   LogifyTest.mq5 |
//|                                  Copyright 2023, MetaQuotes Ltd. |
//|                                             https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2023, MetaQuotes Ltd."
#property link      "https://www.mql5.com"
#property version   "1.00"
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
//---
   
//---
   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+
//| Expert deinitialization function                                 |
//+------------------------------------------------------------------+
void OnDeinit(const int reason)
  {
//---
   
  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
  {
//---
   
  }
//+------------------------------------------------------------------+

Binden Sie die Hauptbibliotheksdatei ein und instanziieren Sie die Klasse CLogify: 

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
#include <Logify/Logify.mqh>
CLogify logify;

Fügen Sie in der Funktion OnInit Protokollierungsaufrufe hinzu, um alle verfügbaren Ebenen zu testen: 

//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
//---
   logify.Debug("RSI indicator value calculated: 72.56", "Indicators", "Period: 14");
   logify.Infor("Buy order sent successfully", "Order Management", "Symbol: EURUSD, Volume: 0.1");
   logify.Alert("Stop Loss adjusted to breakeven level", "Risk Management", "Order ID: 12345678");
   logify.Error("Failed to send sell order", "Order Management", "Reason: Insufficient balance");
   logify.Fatal("Failed to initialize EA: Invalid settings", "Initialization", "Missing or incorrect parameters");
//---
   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+

Bei der Ausführung des Codes werden die erwarteten Meldungen im MetaTrader 5-Terminal wie unten dargestellt:



Schlussfolgerung

Die Logify-Bibliothek wurde erfolgreich getestet und zeigt Protokollmeldungen für alle verfügbaren Ebenen korrekt an. Diese Grundstruktur ermöglicht eine organisierte und erweiterbare Protokollverwaltung und bietet eine solide Grundlage für künftige Verbesserungen, wie z. B. die Integration mit Datenbanken, Dateien oder Diagrammen.

Mit einer modularen Implementierung und einfach zu bedienenden Methoden bietet Logify Flexibilität und Klarheit beim Log-Management in MQL5-Anwendungen. Die nächsten Schritte können die Erstellung alternativer Ausgaben und das Hinzufügen dynamischer Einstellungen zur Anpassung des Bibliotheksverhaltens umfassen. Wir sehen uns im nächsten Artikel!

Übersetzt aus dem Englischen von MetaQuotes Ltd.
Originalartikel: https://www.mql5.com/en/articles/16447

Beigefügte Dateien |
ZIP herunterladen
LogifyoPart11.zip (4.01 KB)
Warnung: Alle Rechte sind von MetaQuotes Ltd. vorbehalten. Kopieren oder Vervielfältigen untersagt.

Andere Artikel von diesem Autor

Zur Diskussion im Händlerforum
MQL5-Assistenten-Techniken, die Sie kennen sollten (Teil 50): Der Awesome Oszillator MQL5-Assistenten-Techniken, die Sie kennen sollten (Teil 50): Der Awesome Oszillator
Der Awesome Oscillator ist ein weiterer Bill-Williams-Indikator, der zur Messung des Momentums verwendet wird. Es kann mehrere Signale generieren, und deshalb überprüfen wir diese auf der Basis von Mustern, wie in früheren Artikeln, indem wir die MQL5-Assistenten-Klassen und -Assembly nutzen.
Entwicklung eines Toolkit zur Analyse von Preisaktionen (Teil 3): Analytics Master — EA Entwicklung eines Toolkit zur Analyse von Preisaktionen (Teil 3): Analytics Master — EA
Der Übergang von einem einfachen Handelsskript zu einem voll funktionsfähigen Expert Advisor (EA) kann Ihre Handelserfahrung erheblich verbessern. Stellen Sie sich vor, Sie hätten ein System, das Ihre Charts automatisch überwacht, wichtige Berechnungen im Hintergrund durchführt und regelmäßig alle zwei Stunden Updates liefert. Dieser EA ist in der Lage, die wichtigsten Kennzahlen zu analysieren, die für fundierte Handelsentscheidungen wichtig sind, und stellt sicher, dass Sie Zugang zu den aktuellsten Informationen haben, um Ihre Strategien effektiv anzupassen.
Handel mit dem MQL5 Wirtschaftskalender (Teil 4): Implementierung von Echtzeit-Nachrichtenaktualisierungen im Dashboard Handel mit dem MQL5 Wirtschaftskalender (Teil 4): Implementierung von Echtzeit-Nachrichtenaktualisierungen im Dashboard
Dieser Artikel erweitert unser Wirtschaftskalender-Dashboard durch die Implementierung von Echtzeit-Nachrichten-Updates, um Marktinformationen aktuell und umsetzbar zu halten. Wir integrieren Techniken zum Abrufen von Live-Daten in MQL5, um Ereignisse auf dem Dashboard kontinuierlich zu aktualisieren und die Reaktionsfähigkeit der Schnittstelle zu verbessern. Dieses Update stellt sicher, dass wir direkt über das Dashboard auf die neuesten Wirtschaftsnachrichten zugreifen können, um unsere Handelsentscheidungen auf der Grundlage der aktuellsten Daten zu optimieren.
Automatisieren von Handelsstrategien in MQL5 (Teil 1): Das Profitunity System (Trading Chaos von Bill Williams) Automatisieren von Handelsstrategien in MQL5 (Teil 1): Das Profitunity System (Trading Chaos von Bill Williams)
In diesem Artikel untersuchen wir das Profitunity System von Bill Williams, indem wir seine Kernkomponenten und seinen einzigartigen Ansatz für den Handel im Marktchaos aufschlüsseln. Wir führen die Leser durch die Implementierung des Systems in MQL5 und konzentrieren uns dabei auf die Automatisierung von Schlüsselindikatoren und Einstiegs-/Ausstiegssignalen. Schließlich testen und optimieren wir die Strategie und geben Einblicke in ihre Leistung in verschiedenen Marktszenarien.