Einstellen des Protokolliergrads¶
Sie können den Schweregrad der Protokollmeldungen festlegen, die in der Ereignistabelle gespeichert werden sollen. Dazu setzen Sie den Parameter LOG_LEVEL auf einen bestimmten Protokolliergrad. Meldungen dieses Grads (und mit höherem Schweregrad) werden dann in der Ereignistabelle erfasst.
LOG_LEVEL ist sowohl ein Objektparameter als auch ein Sitzungsparameter, d. h. Sie können den Parameter für Objekte und Sitzungen festlegen.
Bemerkung
Sie können Handler-Code verwenden, um den mit SQL eingestellten Protokolliergrad (wie unter diesem Thema beschrieben) zu überschreiben, wenn Ihr Handler in Python geschrieben ist. Weitere Informationen dazu finden Sie unter Überschreiben von Protokollschwellenwerten mit Python.
Erläuterungen zum Protokolliergrad¶
Wenn Sie den Parameter LOG_LEVEL auf den angegebenen Protokolliergrad festlegen, werden nur Meldungen des angegebenen Grads (und Meldungen mit höherem Schweregrad) erfasst und in der Ereignistabelle zur Verfügung gestellt.
Wenn Sie beispielsweise den Parameter LOG_LEVEL auf WARN setzen, werden Meldungen der Schweregrade WARN, ERROR und FATAL in der Ereignistabelle erfasst.
Eine Liste der LOG_LEVEL
-Werte mit den entsprechenden Schweregraden der erfassten Meldungen finden Sie unter LOG_LEVEL.
Einstellen des Protokolliergrads für ein Objekt¶
Sie können den Protokolliergrad für die folgenden Objekte festlegen:
Gespeicherte Prozedur
Benutzerdefinierte Funktion (UDF) oder benutzerdefinierte Tabellenfunktion (UDTF)
Datenbank oder Schema mit entsprechenden Prozeduren und Funktionen
Gehen Sie wie folgt vor, um den Protokolliergrad für ein Objekt festzulegen:
Überprüfen Sie, ob Sie die Berechtigung haben, den Protokolliergrad für das Objekt festzulegen.
Sie müssen eine Rolle verwenden, der die folgenden Berechtigungen erteilt wurden oder die diese geerbt hat:
Die globale Berechtigung MODIFY LOG LEVEL für das Konto
Die Berechtigung MODIFY für das Objekt, für das Sie den LOG_LEVEL-Wert festlegen möchten
Um beispielsweise der Rolle
central_log_admin
die Berechtigung zu erteilen, den Protokolliergrad für jede Datenbank, jedes Schema, jede gespeicherte Prozedur, UDF oder UDTF im Konto festzulegen (auch für solche, für die die Rollecentral_log_admin
keine anderen Berechtigungen hat), führen Sie die folgende Anweisung aus:GRANT MODIFY LOG LEVEL ON ACCOUNT TO ROLE central_log_admin;
Wenn Sie den Protokolliergrad für eine gespeicherte Prozedur oder UDF festlegen möchten, müssen Sie beachten, dass der Rolle
central_log_admin
auch die Berechtigung USAGE für die Datenbank/das Schema zugewiesen sein muss, die/das die gespeicherte Prozedur oder UDF enthält.Weitere Informationen zu den Berechtigungen MODIFY LOG LEVEL und USAGE finden Sie unter Zugriffssteuerungsrechte.
Verwenden Sie den Befehl ALTER <Objekt>, um den Parameter LOG_LEVEL für das Objekt festzulegen.
Eine Liste der möglichen Protokolliergrade finden Sie unter dem Parameter LOG_LEVEL. Wie bereits erwähnt, werden Meldungen des angegebenen Schweregrads (und mit höherem Schweregrad) in der aktiven Ereignistabelle erfasst.
Um beispielsweise den Protokolliergrad für eine bestimmte UDF einzustellen, verwenden Sie ALTER FUNCTION zum Einstellen des Parameters LOG_LEVEL für diese UDF. Oder um beispielsweise den Standard-Protokolliergrad für alle Funktionen und Prozeduren in einer Datenbank festzulegen, verwenden Sie ALTER DATABASE zum Einstellen des Parameters LOG_LEVEL für diese Datenbank.
Im folgenden Beispiel wird der Protokolliergrad für alle Funktionen und Prozeduren in der Datenbank
db
auf ERROR gesetzt. Das Beispiel ändert den Protokolliergrad der UDFf1(int)
in WARN.USE ROLE central_log_admin; -- Set the log levels on a database and UDF. ALTER DATABASE db1 SET LOG_LEVEL = ERROR; ALTER FUNCTION f1(int) SET LOG_LEVEL = WARN;
Weitere Informationen dazu, wie Snowflake den effektiven Protokolliergrad bestimmt, wenn der LOG LEVEL auf verschiedene Objekte gesetzt ist, finden Sie unter Erläuterungen zur Bestimmung des effektiven Protokolliergrads durch Snowflake.
Einstellen des Protokolliergrads für die aktuelle Sitzung¶
So stellen Sie den Protokolliergrad für Aufrufe von Funktionen und Prozeduren in der aktuellen Sitzung ein:
Überprüfen Sie, ob Sie die Berechtigung haben, den Protokolliergrad für das Objekt festzulegen.
Sie müssen eine Rolle verwenden, der die globale Berechtigung MODIFY SESSION LOG LEVEL für das Konto zugewiesen wurde.
Um beispielsweise der Rolle
developer_debugging
die Berechtigung zuzuweisen, die Protokolliergrade für die aktuelle Sitzung festzulegen, führen Sie die folgende Anweisung aus:GRANT MODIFY SESSION LOG LEVEL ON ACCOUNT TO ROLE developer_debugging;
Verwenden Sie den Befehl ALTER SESSION, um den Parameter LOG_LEVEL für die aktuelle Sitzung festzulegen.
Beispiel:
USE ROLE developer_debugging; -- Set the logging level to DEBUG for the current session. ALTER SESSION SET LOG_LEVEL = DEBUG;
Wenn der Parameter LOG_LEVEL für die aktuelle Sitzung und für die in dieser Sitzung aufgerufenen Funktionen und Prozeduren auf unterschiedliche Protokolliergrade eingestellt ist, bestimmt Snowflake den effektiv zu verwendenden Protokolliergrad. Siehe Erläuterungen zur Bestimmung des effektiven Protokolliergrads durch Snowflake.
Erläuterungen zur Bestimmung des effektiven Protokolliergrads durch Snowflake¶
Sie können den Parameter LOG_LEVEL (sowohl für Objekte als auch für Sitzungen) unter Verwendung einer Hierarchie ändern. Mit anderen Worten: Sie können den LOG_LEVEL, der auf einer höheren Ebene in der Hierarchie festgelegt wurde, auf einer niedrigeren Ebene mit dem LOG_LEVEL für ein Objekt überschreiben.
Im Folgenden wird die Hierarchie der LOG_LEVEL-Parameter für Sitzungen und Objekte beschrieben.
Die Hierarchie für Sitzungsparameter ist: Konto » Benutzer » Sitzung.
Das bedeutet: Sie können den Parameter für ein Konto festlegen, und dann können Sie den Parameter für einen Benutzer auf Kontoebene überschreiben und Sie können den Parameter für die aktuelle Sitzung auf Benutzerebene überschreiben.
Die Hierarchie für Objektparameter ist: Konto » Datenbank » Schema » Objekt.
Das bedeutet: Sie können den Parameter für ein Konto festlegen, und dann können Sie den Parameter für eine Datenbank oder ein Schema auf Kontoebene überschreiben und Sie können den Datenbank- bzw. Schema-spezifischen Parameter für gespeicherte Prozeduren und UDFs in dieser Datenbank bzw. in diesem Schema überschreiben.
So überschreibt beispielsweise der LOG_LEVEL für eine Funktion den LOG_LEVEL für das Konto, das die Funktion enthält. Wenn der LOG_LEVEL für das Konto FATAL ist und der LOG_LEVEL für die Java-UDF in dem Konto INFO ist, dann ist der effektive LOG_LEVEL INFO (der Grad für die Funktion, nicht der Grad für das Konto):
ALTER ACCOUNT SET LOG_LEVEL = FATAL;
ALTER FUNCTION MYJAVAUDF SET LOG_LEVEL = INFO;
-- The INFO log level is used because the FUNCTION MYJAVAUDF
-- is lower than the ACCOUNT in the hierarchy.
In Fällen, in denen LOG_LEVEL sowohl in der Sitzungs- als auch in der Objektparameterhierarchie gesetzt ist, wird der ausführlichste LOG_LEVEL verwendet.
In der folgenden Tabelle sind Beispiele dafür aufgeführt, wie sich die für die Sitzung und das Objekt festgelegten Parameter auf den verwendeten Protokolliergrad auswirken.
Wert für Sitzung
Wert für Objekt, Schema, Datenbank oder Konto
Verwendeter Protokolliergrad
(nicht festgelegt)
WARN
WARN
DEBUG
(nicht festgelegt)
DEBUG
WARN
ERROR
WARN
INFO
DEBUG
DEBUG
(nicht festgelegt)
(nicht festgelegt)
OFF
So überschreibt beispielsweise der LOG_LEVEL DEBUG den LOG_LEVEL INFO. Wenn der LOG_LEVEL für die Sitzung DEBUG ist und der LOG_LEVEL für die Java-UDF INFO ist, dann überschreibt der LOG_LEVEL DEBUG für die Sitzung den LOG_LEVEL INFO für die UDF. (DEBUG is more verbose than INFO).
ALTER SESSION SET LOG_LEVEL = DEBUG;
ALTER FUNCTION MYJAVAUDF SET LOG_LEVEL = INFO;
-- The DEBUG log level is used because DEBUG is more verbose than INFO.