- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
Datadog 처리 언어(DPL) 또는 벡터 리매핑 언어(VRL)는 실패를 방지하는 언어이므로 모든 잠재적 오류가 처리되지 않으면 DPL/VRL 프로그램이 컴파일되지 않습니다. 따라서 DPL/VRL 프로그램이 잘못된 구성의 데이터를 처리할 수 있도록 해줍니다.
A root expression is fallible and its runtime error isn’t handled in the DPL program.
DPL is fail safe and thus requires that all possible runtime errors be handled. This provides important safety guarantees to DPL and helps to ensure that DPL programs run reliably when deployed.
Handle the runtime error by assigning, coalescing, or raising the error.
DPL program:
get_env_var("HOST")
How to fix it:
- get_env_var("HOST")
+# .host = get_env_var("HOST")
A regex literal expression is malformed and thus doesn’t result in a valid regular expression.
Invalid regular expressions don’t compile.
Regular expressions are difficult to write and commonly result in syntax errors. If you’re parsing a common
log format we recommend using one of DPL’s parse_* functions. If
you don’t see a function for your format please request it. Otherwise, use the
Rust regex tester to test and correct your regular expression.
DPL program:
. |= parse_regex!(.message, r'^(?P<host>[\w\.]+) - (?P<user>[\w]+) (?P<bytes_in>[\d]+) \[?P<timestamp>.*)\] "(?P<method>[\w]+) (?P<path>.*)" (?P<status>[\d]+) (?P<bytes_out>[\d]+)$')
How to fix it:
-. |= parse_regex!(.message, r'^(?P<host>[\w\.]+) - (?P<user>[\w]+) (?P<bytes_in>[\d]+) \[?P<timestamp>.*)\] "(?P<method>[\w]+) (?P<path>.*)" (?P<status>[\d]+) (?P<bytes_out>[\d]+)$')
+. |= parse_common_log!(.message)
An if expression predicate doesn’t evaluate to a Boolean.
DPL doesn’t implement “truthy” values (non-Boolean values that resolve to a Boolean, such as 1) since these
are common foot-guns that can result in unexpected behavior when used in if expressions. This provides important
safety guarantees in DPL and ensures that DPL programs are reliable once deployed.
Adjust your if expression predicate to resolve to a Boolean. Helpful functions to solve this include
exists and
is_nullish.
DPL program:
if .message {
. |= parse_key_value!(.message)
}
How to fix it:
-if .message {
+if exists(.message) {
. |= parse_key_value!(.message)
}
The right-hand side of this assignment is fallible (that is, it can produce a runtime error), but the error isn’t handled.
DPL is fail safe and thus requires that all possible runtime errors be handled. This provides important safety guarantees to DPL and helps to ensure that DPL programs run reliably when deployed.
Handle the runtime error by either assigning it, coalescing it, or raising it.
DPL program:
. = parse_key_value(.message)
How to fix it:
-. = parse_key_value(.message)
+. = parse_key_value(.message) ?? {}
DPL program:
. = parse_key_value(.message)
How to fix it:
-. = parse_key_value(.message)
+. = parse_key_value!(.message)
DPL program:
. = parse_key_value(.message)
How to fix it:
-. = parse_key_value(.message)
+., err = parse_key_value(.message)
The left-hand side of an assignment expression needlessly handles errors even though the right-hand side can’t fail.
Assigning errors when one is not possible is effectively dead code that makes your program difficult to follow. Removing the error assignment simplifies your program.
Remove the error assignment.
DPL program:
.message, err = downcase(.message)
How to fix it:
-.message, err = downcase(.message)
+.message = downcase(.message)
A function call expression invokes an unknown function.
This is typically due to a typo. Correcting the function name should resolve this.
DPL program:
parse_keyvalue(.message)
How to fix it:
-parse_keyvalue(.message)
+parse_key_value(.message)
A function call expression invokes a function with too many arguments.
Remove the extra arguments to adhere to the function’s documented signature.
DPL program:
parse_json(.message, pretty: true)
How to fix it:
-parse_json(.message, pretty: true)
+parse_json(.message)
A function call expression fails to pass a required argument.
Supply all of the required function arguments to adhere to the function’s documented signature.
DPL program:
parse_timestamp(.timestamp)
How to fix it:
-parse_timestamp(.timestamp)
+parse_timestamp(.timestamp, format: "%D")
A function call expression passes an unknown named argument.
Correct the name to align with the documented argument names for the function.
DPL program:
parse_timestamp(.timestamp, fmt: "%D")
How to fix it:
-parse_timestamp(.timestamp)
+parse_timestamp(.timestamp, format: "%D")
An argument passed to a function call expression isn’t a supported type.
DPL is fail safe and thus requires that all possible runtime errors be handled. This provides important safety guarantees to DPL and helps to ensure that DPL programs run reliably when deployed.
You must guarantee the type of the variable by using the appropriate type or coercion function.
DPL program:
downcase(.message)
How to fix it:
+.message = string(.message) ?? ""
downcase(.message)
DPL program:
downcase(.message)
How to fix it:
downcase(string!(.message))
A predicate is fallible and its runtime error isn’t handled in the DPL program.
DPL is fail safe and thus requires that all possible runtime errors be handled. This provides important safety guarantees to DPL and helps to ensure that DPL programs run reliably when deployed.
Handle the runtime error by assigning, coalescing, or raising the error.
DPL program:
if contains(.field, "thing") {
log("thing")
}
How to fix it:
- if contains(.field, "thing") {
+# if contains(.field, "thing") ?? false {
Your DPL program contains a token (character) that the DPL parser doesn’t recognize as valid.
Use a valid token.
DPL program:
😂
How to fix it:
-😂
+"some valid value"
The DPL parser has reached the end of the program in an invalid state, potentially due to a typo or a dangling expression.
Make sure that the last expression in the program is valid.
DPL program:
.field1 = "value1"
.field2 =
How to fix it:
-.bar =
+.field2 = "value2"
You’ve used a name for a variable that serves another purpose in DPL or is reserved for potential future use.
Use a different variable name.
DPL program:
else = "some value"
How to fix it:
-else = "some value"
+some_non_reserved_name = "some value"
The DPL compiler doesn’t recognize this numeric literal as valid.
Your DPL program contains a string literal that the DPL parser doesn’t recognize as valid.
Make sure that your string is properly enclosed by single or double quotes.
DPL program:
"Houston, we have a problem'
How to fix it:
- "Houston, we have a problem'
+ "Houston, we have a problem"
The DPL compiler doesn’t recognize this literal value as valid.
Your string includes an escape character that the DPL compiler doesn’t recognize as valid
The DPL compiler expected a value of a specific type but found a different type.
This value can’t be coerced into the desired type.
These two types can’t produce a remainder.
These types can’t be multiplied together
The left-hand value can’t be divided by the right-hand value.
You’ve attempted to divide an integer or float by zero.
Unlike some other programming languages, DPL doesn’t have any concept of infinity, as it’s unclear how that could be germane to observability data use cases. Thus, dividing by zero can’t have any meaningful result.
If you know that a value is necessarily zero, don’t divide by it. If a value could be zero, capture the potential error thrown by the operation:
result, err = 27 / .some_value
if err != null {
# Handle error
}
Floats in DPL can’t be NaN (not a number).
These two values can’t be added together.
The right-hand value can’t be subtracted from the left-hand value.
These two values can’t be combined into an or expression.
These two values can’t be combined into an and expression.
These two values can’t be used in a greater than expression.
These two values can’t be used in a greater than or equal to expression.
These two values can’t be used in less than expression.
These two values can’t be used in a less than or equal to expression.
This value is read-only and cannot be deleted or mutated.
The DPL compiler encountered an expression type that wasn’t expected here.
DPL expects an enum value for this argument, but the value you entered for the enum is invalid.
Check the documentation for this function in the DPL functions reference to see which enum values are valid for this argument.
DPL expected a static expression for a function argument, but a dynamic one was provided (such as a variable).
DPL requires static expressions for some function arguments to validate argument types at compile time to avoid runtime errors.
Replace the dynamic argument with a static expression.
An invalid argument was passed to the function. The error string will contain more details about what was invalid.
Check the error string for this error to see what was invalid.
The provided timestamp literal is properly
formed (i.e. it uses t'...' syntax) but the timestamp doesn’t adhere to RFC 3339 format.
Invalid timestamps don’t compile.
Bring the timestamp in conformance with RFC 3339 format.
DPL program:
.timestamp = format_timestamp!(t'next Tuesday', format: "%v %R")
How to fix it:
-.timestamp = format_timestamp!(t'next Tuesday', format: "%v %R")
+.timestamp = format_timestamp!(t'2021-03-09T16:33:02.405806Z', format: "%v %R")
You’ve specified that a function should abort on error even though the function is infallible.
In DPL, infallible functions—functions that can’t fail—don’t require error
handling, which in turn means it doesn’t make sense to abort on failure using a ! in the function call.
Remove the ! from the function call.
DPL program:
encode_json!(["one", "two", "three"])
How to fix it:
- encode_json!(["one", "two", "three"])
+# encode_json(["one", "two", "three"])
You’ve passed a fallible expression as an argument to a function.
In DPL, expressions that you pass to functions as arguments need to be infallible themselves. Otherwise, the outcome of the function would be indeterminate.
Make the expression passed to the function infallible, potentially by aborting on error using !, coalescing
the error using ??, or via some other method.
DPL program:
format_timestamp!(to_timestamp("2021-01-17T23:27:31.891948Z"), format: "%v %R")
How to fix it:
- format_timestamp!(to_timestamp("2021-01-17T23:27:31.891948Z"), format: "%v %R")
+ format_timestamp!(to_timestamp!("2021-01-17T23:27:31.891948Z"), format: "%v %R")
You’ve passed a fallible expression as a message to abort.
An expression that you pass to abort needs to be infallible. Otherwise, the abort expression could fail at runtime.
Make the expression infallible, potentially by handling the error, coalescing the error using ??, or via some other method.
DPL program:
abort to_syslog_level(0)
How to fix it:
- abort to_syslog_level(0)
+ abort to_syslog_level(0) ?? "other"
You’ve assigned a value to something that is neither a variable nor a path.
All assignments in DPL need to be to either a path or a variable. If you try to assign a value to, for example,
underscore (_), this operation is considered a “no-op” as it has no effect (and is thus not an assignment at
all).
Assign the right-hand-side value to either a variable or a path.
DPL program:
_ = "the hills are alive"
How to fix it:
- _ = "the hills are alive"
+# .movie_song_quote = "the hills are alive"
You’ve chained multiple comparison operators together in a way that can’t result in a valid expression.
Comparison operators can only operate on two operands, e.g. 1 != 2. Chaining them together, as in
1 < 2 < 3, produces a meaningless non-expression.
Use comparison operators only on a left-hand- and a right-hand-side value. You can chain comparisons together
provided that the expressions are properly grouped. While a == b == c, for example, isn’t valid,
a == b && b == c is valid because it involves distinct Boolean expressions.
DPL program:
1 == 1 == 2
How to fix it:
- 1 == 1 == 2
+# (1 == 1) && (1 == 2)
You’ve used a coalescing operation (??) to handle an error, but in this case the left-hand
operation is infallible, and so the right-hand value after ?? is never reached.
Error coalescing operations are useful when you want to specify what happens if an operation fails. Here’s an example:
result = op1 ?? op2
In this example, if op1 is infallible (that is, it can’t error) then the result variable
if set to the value of op1 while op2 is never reached.
If the left-hand operation is meant to be infallible, remove the ?? operator and the
right-hand operation. If, however, the left-hand operation is supposed to be fallible,
remove the ! from the function call and anything else that’s making it infallible.
You’re attempting to merge two values together but one or both isn’t an object.
Amongst DPL’s available types, only objects can be merged together. It’s not clear what it would mean to merge, for example, an object with a Boolean. Please note, however, that some other DPL types do have merge-like operations available:
These operations may come in handy if you’ve used merge by
accident.
Make sure that both values that you’re merging are DPL objects. If you’re not sure whether
a value is an object, you can use the object function to
check.
You’ve used the negation operator to negate a non-Boolean expression.
Only Boolean values can be used with the negation operator (!). The expression !false, for example, produces
true, whereas !"hello" is a meaningless non-expression.
Use the negation operator only with Boolean expressions.
DPL program:
!47
How to fix it:
- !47
+# !(47 == 48)
The referenced variable is undefined.
Referencing a variable that is undefined results in unexpected behavior, and is likely due to a typo.
Assign the variable first, or resolve the reference typo.
DPL program:
my_variable
How to fix it:
+my_variable = true
my_variable
DPL program:
my_variable = true
my_var
How to fix it:
-my_var
+my_variable
The referenced item is deprecated. Usually an alternative is given that can be used instead.
This will be removed in the future.
Apply the suggested alternative.
| |