From 4b94752e05c759e45690ab6fe82eee6562a12f29 Mon Sep 17 00:00:00 2001 From: guacbot Date: Fri, 9 May 2025 15:18:37 +0100 Subject: [PATCH 01/29] Deleting translations of content/es/ddsql_editor/reference/data_types.md --- .../es/ddsql_editor/reference/data_types.md | 44 ------------------- 1 file changed, 44 deletions(-) delete mode 100644 content/es/ddsql_editor/reference/data_types.md diff --git a/content/es/ddsql_editor/reference/data_types.md b/content/es/ddsql_editor/reference/data_types.md deleted file mode 100644 index 1d372025b0f45..0000000000000 --- a/content/es/ddsql_editor/reference/data_types.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -aliases: -- /es/dashboards/ddsql_editor/reference/data_types/ -title: Tipos de datos DDSQL ---- - -{{< callout url="https://datadoghq.com/private-beta/ddsql-editor">}} -DDSQL está en Vista previa. -{{< /callout >}} - -## Tipos de datos - -DDSQL implementa una versión simplificada del sistema de tipos SQL que proviene principalmente de PostgreSQL. - -### Tipos de bases - -| Nombre SQL | Alias | Descripción | -|------------|--------------------------|-------------| -| entero | Int | El almacenamiento es siempre int64. | -| texto | char, varchar, cadena | El almacenamiento es siempre UTF-8 de longitud ilimitada. | -| real | doble, decimal | El almacenamiento es siempre IEEE-754 float64. | -| marca de tiempo | marca de tiempo sin zona horaria | Tipo de fecha y hora estándar de SQL. | -| fecha | | Marca de tiempo con resolución a nivel de día. | -| intervalo | | Duración. | -| grupo | hstore, etiqueta_columna | Conjunto ordenado de cadenas con semántica "= es contiene" similar a etiqueta (tag). | -| booleano | | `TRUE` o `FALSE` | -| json | | Datos JSON | - -### Matrices -Las matrices son una colección ordenada de un tipo base específico. Cada tipo base puede tener su correspondiente tipo de matriz. - -### Literales - -La siguiente tabla contiene ejemplos sobre cómo declarar literales para cada tipo, para su uso en expresiones como `SELECT ` o en comparaciones como `WHERE timestamp > timestamp '1 hr ago'`. - -| Nombre | Ejemplo | -|------------|---------| -| entero | `1`, `4`, `23901239412`, `0x4B1D` | -| texto | `'Hello, world'` | -| real | `1.0`, `1e30`, `314e-2`, `.25`, `5.` | -| fecha | `date ` (donde `DATE_STRING` es una cadena que puede convertirse en una fecha, o una cadena relativa como `1 day ago`') | -| marca de tiempo | `timestamp ` (donde `TIMESTAMP_STRING` es una cadena que puede analizarse como una marca de tiempo, o una cadena relativa como `'1 day ago'`, `'now'`) | -| intervalo | `interval ` (donde `INTERVAL` es una cadena que puede analizarse en un intervalo, como `1 day`, `30s`, `2 min`') | -| matrices | `array[values...]` | \ No newline at end of file From 6c1472b63ed73d740180f6e321ac56d4db1c55bb Mon Sep 17 00:00:00 2001 From: guacbot Date: Fri, 9 May 2025 15:19:32 +0100 Subject: [PATCH 02/29] Deleting translations of content/es/ddsql_editor/reference/tags.md --- content/es/ddsql_editor/reference/tags.md | 68 ----------------------- 1 file changed, 68 deletions(-) delete mode 100644 content/es/ddsql_editor/reference/tags.md diff --git a/content/es/ddsql_editor/reference/tags.md b/content/es/ddsql_editor/reference/tags.md deleted file mode 100644 index d48323e62de22..0000000000000 --- a/content/es/ddsql_editor/reference/tags.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -aliases: -- /es/dashboards/ddsql_editor/reference/tags/ -title: Consulta de etiquetas en DDSQL ---- - -{{< callout url="https://datadoghq.com/private-beta/ddsql-editor">}} -DDSQL está en vista previa. -{{< /callout >}} - -Las etiquetas (tags) son un mecanismo muy conocido para codificar metadatos sobre un registro concreto en varios productos en Datadog. Las etiquetas son pares de clave-valor para los que una clave puede contener varios valores. - -Las etiquetas se modelan en DDSQL con la clave como nombre de columna y los valores en un tipo `group`, un conjunto ordenado de cadenas con semántica "= is contains" similar a etiquetas. - -## Comparaciones de igualdad - -Las comparaciones de igualdad entre etiquetas y cadenas se tratan como una comparación "contains" en lugar de requerir una igualdad estricta. `service='website'` es verdadero si un registro tiene una etiqueta `service` con el valor `website`, aunque también tenga otras etiquetas de servicio. - -Como consecuencia de este comportamiento, el operador `IN` con etiquetas funciona como un "solapamiento". Por ejemplo, `service IN ('webstore', 'webstore-analytics')` coincide con registros que contengan `service:webstore`, `service:webstore-analytics`, o ambos, aunque haya otras etiquetas de servicio presentes (por ejemplo, `service:webstore,something-else` coincide). - -## Comparaciones de igualdad estricta - -Para realizar una comparación estricta, convierte la referencia de etiqueta en una cadena o compárala con un literal de grupo en una consulta externa. Por ejemplo, una consulta del tipo - -{{< code-block lang="sql" >}} -SELECT * FROM host WHERE team='logs' GROUP BY team; -{{< /code-block >}} - -Puede devolver el siguiente resultado: - -| team | -|------------------| -| logs | -| logs,team2 | -| logs,team3,team4 | -| logs,team2,team4 | - -Para buscar sólo en `logs`, utiliza esta consulta: - -{{< code-block lang="sql" >}} -SELECT * FROM host WHERE team={'logs'} GROUP BY team; -{{< /code-block >}} - -Esta comparación más estricta sólo devuelve un resultado: - -| team | -|------------------| -| logs | - -## Referencias de etiqueta implícitas - -Las referencias de esquema de lectura en tablas que admiten etiquetas se tratan como búsquedas de etiquetas y se denominan referencias de etiqueta implícitas. - -Por ejemplo, la columna `az` no existe en la tabla `resources.host`, pero puedes `SELECT az FROM resources.host`. DDSQL reconoce que la tabla `resources.host` admite esquema en lectura, y `az` se convierte en una referencia de etiqueta implícita. Su nombre en la proyección es `az`, que puede utilizarse en toda la consulta. - -## Referencias de etiqueta explícitas - -Las referencias de etiqueta explícitas permiten al usuario especificar que una referencia de columna debe referirse a una etiqueta incluso si existe una columna con un nombre idéntico en el esquema de la tabla. Las referencias de etiqueta explícitas permiten una defensa básica contra las actualizaciones del esquema que cambian el significado de las consultas basadas en el comportamiento implícito. - -Las referencias de etiqueta explícitas son referencias a columnas precedidas por el carácter `#`. Por ejemplo, la tabla `resources.host` contiene una columna `service`, pero la consulta puede hacer referencia explícita a la etiqueta `service`: - -{{< code-block lang="sql" >}} -SELECT #service FROM resources.host -{{< /code-block >}} - -El nombre de etiqueta en la proyección es `#service`, que debe utilizarse en toda la consulta, ya que `service` hace referencia a la columna del esquema. - -Para las referencias de etiqueta que requieren comillas, el `#` debe aparecer fuera de las comillas (por ejemplo, `#"availability-zone"`). Esto es necesario para diferenciar entre referencias de etiqueta explícitas y columnas que comienzan con un carácter `#`. \ No newline at end of file From dbf6f60af960fef515c4a1c55f58fb045f447924 Mon Sep 17 00:00:00 2001 From: guacbot Date: Fri, 9 May 2025 15:21:17 +0100 Subject: [PATCH 03/29] Deleting translations of content/es/logs/workspaces/sql_reference.md --- content/es/logs/workspaces/sql_reference.md | 293 -------------------- 1 file changed, 293 deletions(-) delete mode 100644 content/es/logs/workspaces/sql_reference.md diff --git a/content/es/logs/workspaces/sql_reference.md b/content/es/logs/workspaces/sql_reference.md deleted file mode 100644 index 96a37eb8e404d..0000000000000 --- a/content/es/logs/workspaces/sql_reference.md +++ /dev/null @@ -1,293 +0,0 @@ ---- -further_reading: -- link: /logs/workspaces/ - tag: Documentación - text: Más información sobre Log Workspaces -title: Referencia de SQL ---- - -## Información general - -SQL en [Celdas de análisis][1] te permite analizar y manipular datos dentro de Log Workspaces. Esta documentación aborda el soporte de SQL disponible en Log Workspaces e incluye: -- [Sintaxis compatible con PostgreSQL](#syntax) -- [Funciones de SQL](#functions) -- [Funciones de ventana](#window-functions) - -{{< img src="/logs/workspace/sql_reference/sql_syntax_analysis_cell.png" alt="Celda de Workspace de ejemplo con sintaxis de SQL" style="width:100%;" >}} - -## Sintaxis - -Se admite la siguiente sintaxis de SQL: - -| Sintaxis | Descripción | Ejemplo | -|---------------|----------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------| -| `SELECT (DISTINCT)`
DISTINCT: opcional | Recupera filas de una base de datos, con `DISTINCT` filtrando los registros duplicados. | {{< code-block lang="sql" >}}SELECT DISTINCT customer_id -FROM orders {{< /code-block >}} | -| `JOIN` | Combines rows from two or more tables based on a related column between them. Supports FULL JOIN, INNER JOIN, LEFT JOIN, RIGHT JOIN. | {{< code-block lang="sql" >}}SELECT orders.order_id, customers.customer_name -FROM orders -JOIN customers -ON orders.customer_id = customers.customer_id {{< /code-block >}} | -| `GROUP BY` | Groups rows that have the same values in specified columns into summary rows. | {{< code-block lang="sql" >}}SELECT product_id, SUM(quantity) -FROM sales -GROUP BY product_id {{< /code-block >}} | -| `WHERE`
Includes support for `LIKE`, `IN`, `ON`, `OR` filters. | Filters records that meet a specified condition. | {{< code-block lang="sql" >}}SELECT * -FROM employees -WHERE department = 'Sales' AND name LIKE 'J%' {{< /code-block >}} | -| `CASE` | Provides conditional logic to return different values based on specified conditions. | {{< code-block lang="sql" >}}SELECT order_id, - CASE - WHEN quantity > 10 THEN 'Bulk Order' - ELSE 'Standard Order' - END AS order_type -FROM orders {{< /code-block >}} | -| `WINDOW` | Performs a calculation across a set of table rows that are related to the current row. | {{< code-block lang="sql" >}}SELECT - timestamp, - service_name, - cpu_usage_percent, - AVG(cpu_usage_percent) OVER (PARTITION BY service_name ORDER BY timestamp ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS moving_avg_cpu -FROM - cpu_usage_data {{< /code-block >}} | -| `IS NULL` / `IS NOT NULL` | Checks if a value is null or not null. | {{< code-block lang="sql" >}}SELECT * -FROM orders -WHERE delivery_date IS NULL {{< /code-block >}} | -| `LIMIT` | Specifies the maximum number of records to return. | {{< code-block lang="sql" >}}SELECT * -FROM customers -LIMIT 10 {{< /code-block >}} | -| `ORDER BY` | Sorts the result set of a query by one or more columns. Includes ASC, DESC for sorting order. | {{< code-block lang="sql" >}}SELECT * -FROM sales -ORDER BY sale_date DESC {{< /code-block >}} | -| `HAVING` | Filters records that meet a specified condition after grouping. | {{< code-block lang="sql" >}}SELECT product_id, SUM(quantity) -FROM sales -GROUP BY product_id -HAVING SUM(quantity) > 10 {{< /code-block >}} | -| `IN`, `ON`, `OR` | Used for specified conditions in queries. Available in `WHERE`, `JOIN` clauses. | {{< code-block lang="sql" >}}SELECT * -FROM orders -WHERE order_status IN ('Shipped', 'Pending') {{< /code-block >}} | -| `AS` | Renames a column or table with an alias. | {{< code-block lang="sql" >}}SELECT first_name AS name -FROM employees {{< /code-block >}} | -| Arithmetic Operations | Performs basic calculations using operators like `+`, `-`, `*`, `/`. | {{< code-block lang="sql" >}}SELECT price, tax, (price * tax) AS total_cost -FROM products {{< /code-block >}} | -| `INTERVAL value unit` | interval | Represents a time duration specified in a given unit. | - - -## Funciones - -Se admiten las siguientes funciones de SQL. Para la función de ventana, consulta la sección [función de ventana](#window-functions) de esta documentación. - -| Función | Tipo de retorno | Descripción | -|--------------------------------------------------|---------------------------------------|-----------------------------------------------------------------------------| -| `min(variable v)` | Variable typeof | Devuelve el valor más pequeño de un conjunto de datos. | -| `max(variable v)` | Variable typeof | Devuelve el valor máximo de todos los valores de entrada. | -| `count(any a)` | numérico | Devuelve el número de valores de entrada que no son nulos. | -| `sum(numeric n)` | numérico | Devuelve la suma de todos los valores de entrada. | -| `avg(numeric n)` | numérico | Devuelve el valor medio (media aritmética) de todos los valores de entrada. | -| `ceil(numeric n)` | numérico | Devuelve el valor redondeado al entero más próximo. | -| `floor(numeric n)` | numérico | Devuelve el valor redondeado al entero más próximo. | -| `round(numeric n)` | numérico | Devuelve el valor redondeado al entero más próximo. | -| `lower(string s)` | cadena | Devuelve la cadena en minúsculas. | -| `upper(string s)` | cadena | Devuelve la cadena en mayúsculas. | -| `abs(numeric n)` | numérico | Devuelve el valor absoluto. | -| `coalesce(args a)` | typeof first non-null a OR null | Devuelve el primer valor no nulo o nulo si todos son nulos. | -| `cast(value AS type)` | tipo | Convierte el valor dado al tipo de datos especificado. | -| `length(string s)` | entero | Devuelve el número de caracteres de la cadena. | -| `trim(string s)` | cadena | Elimina los espacios en blanco iniciales y finales de la cadena. | -| `replace(string s, from_string s1, to_string s2)`| cadena | Sustituye las apariciones de una subcadena dentro de una cadena por otra subcadena. | -| `substring(string s, start_position_int i, length_int l)` | cadena | Extrae una subcadena de una cadena, comenzando en una posición dada y para una longitud especificada. | -| `extract(field from timestamp/interval)` | numérico | Extrae una parte de un campo de fecha u hora (como el año o el mes) de una marca temporal o intervalo. | -| `to_timestamp(numeric n)` | marca temporal con huso horario | Convierte un valor numérico en una marca temporal con huso horario. | -| `to_char(timestamp t / interval i / numeric n, format f)` | cadena | Convierte una marca temporal, un intervalo o un valor numérico en una cadena utilizando un formato.| -| `date_trunc(field f, source [, time_zone])` | marca temporal [con huso] / intervalo | Trunca una marca temporal o un intervalo con una precisión especificada. | -| `regexp_like(string s, pattern p [flags])` | booleano | Evalúa si una cadena coincide con un patrón de expresión regular. | - - -{{% collapse-content title="Ejemplos" level="h3" %}} - -### `MIN` -{{< code-block lang="sql" >}} -SELECT MIN(response_time) AS min_response_time -FROM logs -WHERE status_code = 200 -{{< /code-block >}} - -### `MAX` -{{< code-block lang="sql" >}} -SELECT MAX(response_time) AS max_response_time -FROM logs -WHERE status_code = 200 -{{< /code-block >}} - -### `COUNT` -{{< code-block lang="sql" >}}SELECT COUNT(request_id) AS total_requests -FROM logs -WHERE status_code = 200 {{< /code-block >}} - -### `SUM` -{{< code-block lang="sql" >}}SELECT SUM(bytes_transferred) AS total_bytes -FROM logs -GROUP BY service_name -{{< /code-block >}} - -### `AVG` -{{< code-block lang="sql" >}}SELECT AVG(response_time) -AS avg_response_time -FROM logs -WHERE status_code = 200 -GROUP BY service_name -{{< /code-block >}} - -### `CEIL` -{{< code-block lang="sql" >}} -SELECT CEIL(price) AS rounded_price -FROM products -{{< /code-block >}} - -### `FLOOR` -{{< code-block lang="sql" >}} -SELECT FLOOR(price) AS floored_price -FROM products -{{< /code-block >}} - -### `ROUND` -{{< code-block lang="sql" >}} -SELECT ROUND(price) AS rounded_price -FROM products -{{< /code-block >}} - -### `LOWER` -{{< code-block lang="sql" >}} -SELECT LOWER(customer_name) AS lowercase_name -FROM customers -{{< /code-block >}} - -### `UPPER` -{{< code-block lang="sql" >}} -SELECT UPPER(customer_name) AS uppercase_name -FROM customers -{{< /code-block >}} - -### `ABS` -{{< code-block lang="sql" >}} -SELECT ABS(balance) AS absolute_balance -FROM accounts -{{< /code-block >}} - -### `COALESCE` -{{< code-block lang="sql" >}} -SELECT COALESCE(phone_number, email) AS contact_info -FROM users -{{< /code-block >}} - -### `CAST` -{{< code-block lang="sql" >}} -SELECT - CAST(order_id AS VARCHAR) AS order_id_string, - 'Order-' || CAST(order_id AS VARCHAR) AS order_label -FROM - orders -{{< /code-block >}} - -### `LENGTH` -{{< code-block lang="sql" >}} -SELECT - customer_name, - LENGTH(customer_name) AS name_length -FROM - customers -{{< /code-block >}} - -### `INTERVAL` -{{< code-block lang="sql" >}} -SELECT - TIMESTAMP '2023-10-01 10:00:00' + INTERVAL '30 days' AS future_date -{{< /code-block >}} - -### `TRIM` -{{< code-block lang="sql" >}} -SELECT - trim(name) AS trimmed_name -FROM - users -{{< /code-block >}} - -### `REPLACE` -{{< code-block lang="sql" >}} -SELECT - replace(description, 'old', 'new') AS updated_description -FROM - products -{{< /code-block >}} - -### `SUBSTRING` -{{< code-block lang="sql" >}} -SELECT - substring(title, 1, 10) AS short_title -FROM - books -{{< /code-block >}} - -### `EXTRACT` -{{< code-block lang="sql" >}} -SELECT - extract(year FROM purchase_date) AS purchase_year -FROM - sales -{{< /code-block >}} - -### `TO_TIMESTAMP` -{{< code-block lang="sql" >}} -SELECT - to_timestamp(epoch_time) AS formatted_time -FROM - event_logs -{{< /code-block >}} - -### `TO_CHAR` -{{< code-block lang="sql" >}} -SELECT - to_char(order_date, 'MM-DD-YYYY') AS formatted_date -FROM - orders -{{< /code-block >}} - -### `DATE_TRUNC` -{{< code-block lang="sql" >}} -SELECT - date_trunc('month', event_time) AS month_start -FROM - events -{{< /code-block >}} - -### `REGEXP_LIKE` -{{< code-block lang="sql" >}} -SELECT - * -FROM - emails -WHERE - regexp_like(email_address, '@example\.com$') -{{< /code-block >}} - -{{% /collapse-content %}} - -## Funciones de ventana - -Esta tabla brinda una visión general de las funciones de ventana compatibles. Para más detalles y ejemplos, consulta la [Documentación de PostgreSQL][2]. - -| Función | Tipo de retorno | Descripción | -|-------------------------|-------------------|------------------------------------------------------------------------| -| `OVER` | N/A | Define una ventana para un conjunto de filas sobre las que pueden operar otras funciones de ventana. | -| `PARTITION BY` | N/A | Divide el conjunto de resultados en particiones, específicamente para aplicar funciones de ventana. | -| `RANK()` | entero | Asigna un rango a cada fila dentro de una partición, con espacios para los empates. | -| `ROW_NUMBER()` | entero | Asigna un número secuencial único a cada fila dentro de una partición. | -| `LEAD(column n)` | columna typeof | Devuelve el valor de la siguiente fila de la partición. | -| `LAG(column n)` | columna typeof | Devuelve el valor de la fila anterior de la partición. | -| `FIRST_VALUE(column n)` | columna typeof | Devuelve el primer valor de un conjunto ordenado de valores. | -| `LAST_VALUE(column n)` | columna typeof | Devuelve el último valor de un conjunto ordenado de valores. | -| `NTH_VALUE(column n, offset)`| columna typeof | Devuelve el valor en el desplazamiento especificado en un conjunto ordenado de valores. | - - -## Referencias adicionales - -{{< partial name="whats-next/whats-next.html" >}} - -[1]: /es/logs/workspaces/#analysis-cell -[2]: https://www.postgresql.org/docs/current/functions-window.html \ No newline at end of file From 53964c6c38bb1c0773355e91616140d88410f1cb Mon Sep 17 00:00:00 2001 From: guacbot Date: Fri, 9 May 2025 15:22:09 +0100 Subject: [PATCH 04/29] Deleting translations of content/es/ddsql_editor/reference/statements.md --- .../es/ddsql_editor/reference/statements.md | 194 ------------------ 1 file changed, 194 deletions(-) delete mode 100644 content/es/ddsql_editor/reference/statements.md diff --git a/content/es/ddsql_editor/reference/statements.md b/content/es/ddsql_editor/reference/statements.md deleted file mode 100644 index 94b5b5071c6f9..0000000000000 --- a/content/es/ddsql_editor/reference/statements.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -aliases: -- /es/dashboards/ddsql_editor/reference/statements/ -title: Sentencias DDSQL ---- - -{{< callout url="https://datadoghq.com/private-beta/ddsql-editor">}} -DDSQL está en vista previa. -{{< /callout >}} - -## SELECT - -`SELECT` recupera filas de una tabla o vista. - -### Sintaxis - -{{< code-block lang="text" >}} -SELECT [ ALL | DISTINCT ] select_expr, ... -[ FROM rel_source - [ EVENT_SEARCH 'message_pattern' ] - [ USE EVENT_INDEX 'index_name' ] - [ [ join_type ] JOIN rel_source ... - [ ON condition | USING (column, ... ) ] ] ... ] -[ WHERE condition ] -[ GROUP BY [ ALL | DISTINCT ] expression, ... ] -[ HAVING condition, ... ] -[ ORDER BY expression, ... [ ASC | DESC ] [ NULLS FIRST | NULLS LAST ] ] -[ LIMIT [ ALL | expression ] - [ OFFSET expression ] ] -{{< /code-block >}} - -#### Tipos de parámetros - -`select_expr` -: cualquier expresión que devuelva un valor. Puede ser una constante, una llamada a función, un agregado, una ventana o la expresión especial `*`. Es la parte de la consulta que especifica la salida de la sentencia SELECT, y en álgebra relacional se conoce como proyección. - -`message_pattern` -: un patrón textual para la [búsqueda de texto completo][1], cuando esté disponible. - -`index_name` -: un identificador para un [índice de logs][2]. - -`rel_source` -: una correlación (un nombre de tabla o alias) o una [expresión DQL][3] entre paréntesis. - -`join_type` -: el tipo de unión SQL, como `INNER` o `LEFT`. Las uniones `INNER` son totalmente compatibles. Las uniones `OUTER` y `CROSS` pueden requerir una condición `WHERE`. Las uniones `LEFT` y `RIGHT` también son compatibles si la condición es una expresión *equijoin*: una comparación de igualdad como ` = ` en la que las expresiones hacen referencia a columnas de tablas diferentes y los tipos de salida de ambas expresiones son los mismos. También funciona una expresión `USING` `JOIN` que se refiera a una sola columna. - -`condition` -: una expresión que se evalúa e interpreta implícitamente como si tuviera un resultado booleano. - -`expression` -: una expresión de valor. Consulta [Expresiones y operadores][4] para obtener más detalles y ejemplos. - -### Evaluación - -SELECT recupera filas de cero o más tablas. El procesamiento general de SELECT es el siguiente: - -1. Se calculan todos los elementos de `FROM`. Si se especifica más de un elemento, se unen utilizando el tipo de unión especificado. -2. Si se especifica la cláusula `WHERE`, las filas que no cumplan la condición se eliminan de la salida. -3. Si se especifica la cláusula `GROUP BY` o hay llamadas a la función agregada en `selectExpr`, la salida se combina en grupos de filas que coinciden en uno o más valores, y se calculan los agregados. Si `HAVING` está presente, las filas que no satisfacen su condición se eliminan de la salida. -4. Las filas de salida reales se calculan utilizando `selectExpr`. -5. `SELECT DISTINCT` elimina las filas duplicadas del resultado. -6. Si se especifica la cláusula `ORDER BY`, las filas devueltas se ordenan en el orden especificado. -7. Si se especifica la cláusula `LIMIT` o `OFFSET`, se eliminan las filas que no estén en el subconjunto especificado. - -El sistema puede ejecutar la consulta de cualquier forma que asegure la obtención de los resultados especificados por este orden. - -## Alias - -Los alias son nombres sustitutivos de expresiones de salida o elementos `FROM`. Un alias se utiliza por brevedad o para eliminar la ambigüedad de las autouniones (cuando la misma tabla se explora varias veces). - -{{< code-block lang="sql" >}} -SELECT * FROM my_long_hosts_table_name as hosts -{{< /code-block >}} - -Cuando se proporciona un alias en un elemento `FROM`, éste oculta completamente el nombre real de la tabla o función. En el ejemplo anterior, el resto de la expresión DQL debe referirse a `my_long_hosts_table_name` como `hosts`. - -## Ordinales - -`GROUP BY` y `ORDER BY` pueden ser nombres de columnas, expresiones arbitrarias formadas a partir de columnas de entrada o el nombre o número ordinal de una expresión de salida (una expresión `SELECT` ). Los ordinales de las expresiones de salida se indexan en 1. - -Por ejemplo, la salida de esta consulta se ordena primero por `ex3`, luego `ex2` y después `ex1`: - -{{< code-block lang="sql" >}} -SELECT ex1, ex2, ex3 FROM table ORDER BY 3, 2, 1; -{{< /code-block >}} - -## UNION - -`UNION` combina los resultados de dos o más [expresiones DQL][3] en una única tabla de salida. - -### Sintaxis - -{{< code-block lang="text" >}} -DQL_expression UNION [ ALL ] DQL_expression ... -[ ORDER BY expressions [ ASC | DESC ] ] -[ LIMIT [ ALL | expression ] - [ OFFSET expression] ] -{{< /code-block >}} - -#### Tipos de parámetros - -`DQL_expression` -: una sentencia de consulta, por ejemplo, `SELECT`. - -El operador `UNION` elimina las filas duplicadas del resultado. Para conservar las filas duplicadas, utiliza `UNION ALL`: - -{{< code-block lang="sql" >}} -SELECT host_key, CAST(service AS text) AS service, 'from resources' FROM host -UNION ALL -SELECT message, service AS text, 'from logs' FROM logs WHERE env='prod' -ORDER BY service LIMIT 200 OFFSET 10; -{{< /code-block >}} - -Todas las subconsultas de una `UNION` deben tener el mismo esquema de salida. Una consulta que contenga una consulta `UNION` sólo puede tener una expresión `ORDER BY` y `LIMIT`, y ambas deben aparecer al final. Las `UNION`encadenadas sólo pueden tener una expresión `ORDER BY` y `LIMIT` al final. - -## WITH - -`WITH` permite escribir sentencias auxiliares para utilizarlas en una consulta más amplia. - -Las sentencias`WITH`, que también suelen denominarse expresiones de tabla comunes o CTE, pueden considerarse como la definición de tablas temporales que existen para una consulta. Cada sentencia auxiliar de una cláusula `WITH` puede ser cualquier [expresión DQL][3], y la propia cláusula `WITH` se adjunta a una sentencia primaria que también puede ser cualquier expresión DQL que no sea`WITH`. Las sentencias auxiliares posteriores pueden hacer referencia a correlaciones con alias en sentencias auxiliares anteriores. - -### Sintaxis - -{{< code-block lang="sql" >}} -WITH alias [ ( output, schema, column, names, ... ) ] AS ( DQL_expression ) [, ...] DQL_expression -{{< /code-block >}} - -#### Tipos de parámetros - -`DQL_expression` -: una sentencia de consulta, por ejemplo, `SELECT`. - -Las sentencias de modificación de datos como `INSERT`, `UPDATE` y `DELETE` no son compatibles con `WITH`. - -Cada consulta de alias también puede especificar su esquema de salida y los nombres de las columnas. - -## CREATE - -DDSQL permite a los usuarios crear tablas temporales, insertar en ellas, consultarlas y hacer referencia a ellas. Estas tablas no se conservan entre sesiones. - -### Sintaxis - -{{< code-block lang="sql" >}} -CREATE TABLE name ( - column_name column_type - [ PRIMARY KEY [ AUTOINCREMENT ] | NOT NULL | UNIQUE | DEFAULT expression ] ... -) -{{< /code-block >}} - -## INSERT - -La sentencia `INSERT` de DDSQL sigue el estándar SQL. DDSQL sólo permite a los usuarios insertar en tablas temporales que se crean con la sentencia `CREATE`, no en orígenes de datos descendentes. - -### Sintaxis - -{{< code-block lang="sql" >}} -INSERT INTO table_name [ (specific, columns, ...) ] VALUES - ( value1, value2, ... ), - ( value1, value2, ... ), - ... -{{< /code-block >}} - -## SHOW - -
Mientras que la sentencia SHOW forma parte del estándar SQL, los nombres de los parámetros en tiempo de ejecución son experimentales. Los parámetros pueden cambiar de nombre, reescribirse o quedar obsoletos en el futuro.
- -Al ejecutar consultas, DDSQL hace referencia a parámetros de tiempo de ejecución (variables de entorno) que no se especifican en la propia sentencia de consulta, como el intervalo predeterminado que se utilizará para las consultas de métricas si no se especifica `BUCKET BY`, o la marca de hora de inicio y fin de una consulta. - -La sentencia `SHOW` muestra los valores de estas variables. - -### Sintaxis - -{{< code-block lang="sql" >}} -SHOW (ALL | parameter) -{{< /code-block >}} - -`SHOW ALL` muestra todos los parámetros de ejecución disponibles en el sistema DDSQL, y `SHOW ` muestra sólo el parámetro especificado. - -## SET - -Para modificar un parámetro en tiempo de ejecución, utiliza la sentencia `SET`. - -### Sintaxis - -{{< code-block lang="sql" >}} -SET variableName = expression -{{< /code-block >}} - -[1]: /es/logs/explorer/search_syntax/#full-text-search -[2]: /es/logs/log_configuration/indexes/ -[3]: /es/ddsql_editor/#use-sql-syntax-ddsql -[4]: /es/ddsql_editor/reference/expressions_and_operators \ No newline at end of file From a1b253f058bf688fdc6bd8fe31922a9e675e35c2 Mon Sep 17 00:00:00 2001 From: guacbot Date: Fri, 9 May 2025 15:23:56 +0100 Subject: [PATCH 05/29] Deleting translations of content/es/ddsql_editor/guide/ddsql_use_cases.md --- .../es/ddsql_editor/guide/ddsql_use_cases.md | 86 ------------------- 1 file changed, 86 deletions(-) delete mode 100644 content/es/ddsql_editor/guide/ddsql_use_cases.md diff --git a/content/es/ddsql_editor/guide/ddsql_use_cases.md b/content/es/ddsql_editor/guide/ddsql_use_cases.md deleted file mode 100644 index 4260a9b30f9f0..0000000000000 --- a/content/es/ddsql_editor/guide/ddsql_use_cases.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -aliases: -- /es/dashboards/guide/ddsql_use_cases -further_reading: -- link: ddsql_editor/ - tag: Documentation - text: Más información sobre el editor DDSQL -title: Consultas y casos de uso habituales de DDSQL ---- - -## Consultas generales -### Enumerar todas las bibliotecas en los servicios en producción - -{{< code-block lang="sql" disable_copy="false">}} -SELECT - c.service_name, - c.team, - lib.library_name, - lib.eol, - lib.last_commit, - lib.newer_versions_number, - lib.library_version, - lib.latest_version, - lib.ecosystem, - lib.language, - lib.license, - lib.license_type -FROM service_definition c -JOIN library lib ON lib.asset_name = c.service_name -WHERE - lib.env = 'production' - AND lib.relation = 'DIRECT' - AND LOWER(c.domain) = 'domain_name' - AND LOWER(c.vertical) = 'account' - AND LOWER(c.type) = 'service' -ORDER BY lib.newer_versions_number DESC -{{< /code-block >}} - -### Enumerar los servicios que ejecutan una versión antigua del rastreador - -{{< code-block lang="sql" disable_copy="false">}} -SELECT * -FROM service_config -WHERE client_library_version < '1.31.0'; -{{< /code-block >}} - -## AWS - -### Enumerar las instancias de RDS que requieren rotación de certificados SSL/TLS - -{{< code-block lang="sql" disable_copy="false">}} -SELECT account_id, - aws_organisation, - aws_environment db_instance_identifier, - display_name, - ca_certificate_identifier, - engine, - engine_version, - tags -FROM aws_rds_instance -WHERE ca_certificate_identifier like 'rds-ca-2019' -{{< /code-block >}} - -### Enumerar las snapshots de EBS en progreso - -{{< code-block lang="sql" disable_copy="false">}} -SELECT description, - account_id, - progress -FROM aws_ebs_snapshot -WHERE LOWER(state) != 'completed' - and LOWER(state) != 'available' -{{< /code-block >}} - -### Enumerar funciones lambda con un tiempo de ejecución desactualizado específico (en este caso, Python 2.7) - -{{< code-block lang="sql" disable_copy="false">}} -SELECT * -FROM aws_lambda_function -WHERE runtime = 'python2.7' -LIMIT 100; -{{< /code-block >}} - -## Referencias adicionales - -{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file From 7dcd754a5ba968612ece1fe4fa72d6e37503a111 Mon Sep 17 00:00:00 2001 From: guacbot Date: Fri, 9 May 2025 15:24:52 +0100 Subject: [PATCH 06/29] Deleting translations of content/es/ddsql_editor/reference/expressions_and_operators.md --- .../reference/expressions_and_operators.md | 131 ------------------ 1 file changed, 131 deletions(-) delete mode 100644 content/es/ddsql_editor/reference/expressions_and_operators.md diff --git a/content/es/ddsql_editor/reference/expressions_and_operators.md b/content/es/ddsql_editor/reference/expressions_and_operators.md deleted file mode 100644 index db8f909f14691..0000000000000 --- a/content/es/ddsql_editor/reference/expressions_and_operators.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -aliases: -- /es/dashboards/ddsql_editor/reference/expressions_and_operators/ -title: Expresiones y operaciones de DDSQL ---- - -{{< callout url="https://datadoghq.com/private-beta/ddsql-editor">}} -DDSQL está en Vista previa. -{{< /callout >}} - -*Las expresiones de valor* son el lenguaje general de las expresiones utilizado para producir valores para condiciones, `SELECT` expresiones, filtros y cláusulas como `WHERE`, `ORDER BY` y `GROUP BY`. La sintaxis de las expresiones de DDSQL es un superconjunto de la sintaxis de las expresiones de SQL. - -## Operaciones aritméticas - -DDSQL admite la notación aritmética infija binaria y unaria estándar de SQL y muchos otros lenguajes: - -| Operación | Descripción | Ejemplo | Resultado | -|----------|--------------------------|---------|--------| -| + | suma | 2 + 3 | 5 | -| - | resta | 2 - 3 | -1 | -| * | multiplicación | 2 * 3 | 6 | -| / | división (sin truncar) | 5 / 2 | 2.5 | - - -Se aplica el orden estándar de las operaciones. Para controlar el orden de las operaciones, añade paréntesis: `(5 - 2) * 3`. - -## Operaciones de comparación - -DDSQL implementa las siguientes operaciones de comparación: - -| Operación | Descripción | Ejemplo | Resultado | -|----------|------------------------|---------|--------| -| > | mayor que | 2 > 3 | false | -| < | menor que | 2 < 3 | true | -| >= | mayor o igual que | 3 >= 2 | true | -| <= | menor o igual que | 3 <= 2 | false | -| = | igual* | 3 = 3 | true | -| !=, <> | no es igual a | 3 != 3 | false | - -Para las referencias de etiquetas (tags) y los grupos de etiquetas, la operación de igualdad (`=`) se trata como una comparación "contiene". Para más detalles, consulta la [Consulta de etiquetas (tags) en DDSQL][1]. - -## Palabras clave de comparación de SQL - -DDSQL admite las siguientes palabras clave de SQL, que funcionan como operaciones booleanas estándar: - -| Operación | Descripción | Ejemplo | Resultado | -|----------|------------------------|---------|--------| -| `NOT` | Filtra registros basándote en más de una condición. | `SELECT * FROM host WHERE NOT env = 'prod';` | Devuelve todos los hosts que no estén en el entorno de producción. | -| `AND` | Filtra registros basándote en más de una condición. | `SELECT * FROM host WHERE env = 'prod' AND cloud_provider = 'aws';` | Devuelve todos los hosts que estén en el entorno de producción y el proveedor de la nube de AWS. | -| `OR` | Filtra registros basándote en más de una condición. | `SELECT * FROM host WHERE env = 'prod' AND cloud_provider = 'aws';` | Devuelve todos los hosts que estén en el entorno de producción o en el proveedor de la nube de AWS. | - -DDSQL también admite las siguientes palabras clave de comparación, tal y como se definen en el estándar de SQL: - -| Operación | Descripción | Ejemplo | Resultado | -|--------------|------------------------|---------|--------| -| `IS NULL` | Selecciona filas si el campo especificado es nulo. | `SELECT * FROM host WHERE cloud_provider IS NULL;` | Devuelve todas las filas que no contengan datos en la columna `cloud_provider`. | -| `IS NOT NULL`| Selecciona filas si el campo especificado no es nulo. Excluye las filas con datos faltantes. | `SELECT * FROM host WHERE cloud_provider IS NOT NULL;` | Devuelve todas las filas que contengan datos en la columna `cloud_provider`. | -| `LIKE` | Busca un patrón específico en un valor de cadena. Puedes utilizar los siguientes caracteres comodín para definir los patrones:
**Signo de porcentaje (%)**: Representa cero, uno o varios caracteres.
**Subrayado (_)**: Representa un solo carácter. | `SELECT * FROM aws_eks_cluster WHERE LOWER(logging) LIKE '%"enabled":true%';` | Devuelve todas las filas de la tabla `aws_eks_cluster` en las que la columna `logging` sea `"enabled":true`. | -| `NOT LIKE` | Excluye filas de una búsqueda, donde la fila tenga un patrón específico en un valor de cadena. Puedes utilizar los comodines `%` y `_` para la coincidencia de patrones. | `SELECT * FROM aws_eks_cluster WHERE LOWER(logging) NOT LIKE '%"enabled":true%';` | Devuelve todas las filas de la tabla `aws_eks_cluster` en las que el `logging` **no** tenga `"enabled":true%'`. | -| `IN` | Busca varios valores en una cláusula `WHERE`. La operación `IN` es una abreviatura para múltiples condiciones `OR`. | `SELECT * FROM host WHERE cloud_provider IN ('aws', 'gcp');` | Devuelve todas las filas de la tabla `host` en las que el valor de `cloud_provider` sea 'AWS' o 'GCP'.| -| `NOT IN` | Sustituye un conjunto de argumentos con la operación `<>` o `!=` que se combina con la operación `AND` | `SELECT * FROM host WHERE cloud_provider NOT IN ('aws', 'gcp');` | Devuelve todas las filas en las que `cloud_provider` no sea `aws` o `gcp`. | - - -DDSQL admite la palabra clave `BETWEEN` de forma que `a BETWEEN x AND y` sea equivalente a `a >= x AND a <= y`. Consulta [la documentación de Postgres para `BETWEEN`][2] para obtener más detalles. - -## Operaciones lógicas - -| Nombre | Descripción | -|---------|-------------------------| -| Y | Lógica booleana, a & b | -| O | Lógica booleana, a || b | -| XOR | Lógica booleana, a ^ b | -| NO | Lógica booleana, !a | -| ES NULA | Devuelve true para cada fila que sea nula | - - -## CASE - -La expresión `CASE` es una expresión condicional genérica, similar a las sentencias si/o de otros lenguajes de programación. `CASE` tiene dos formas, simple y buscada. - -### Sentencias CASE simples - -Las sentencias CASE simples utilizan la siguiente sintaxis: - -{{< code-block lang="sql" >}} -Expresión CASE - CUANDO valor ENTONCES resultado - [ WHEN ... ] - [ ELSE resultado ] -FIN -{{< /code-block >}} - -La expresión se calcula y luego se compara con cada una de las expresiones de valor de las cláusulas `WHEN` hasta que se encuentre una que sea igual a ella. Si no se encuentra ninguna coincidencia, se devuelve el resultado de la cláusula `ELSE` o `NULL` si se omite `ELSE`. - -### Sentencias CASE buscadas - -Las sentencias CASE buscadas utilizan la siguiente sintaxis: - -{{< code-block lang="sql" >}} -CASE - CUANDO condición ENTONCES resultado - [ WHEN ... ] - [ ELSE resultado ] -FIN -{{< /code-block >}} - -Si el resultado de una condición es true, el valor de la expresión `CASE` es el resultado que sigue a la condición y el resto de la expresión `CASE` no se procesa. Si el resultado de la condición no es true, cualquier cláusula `WHEN` subsiguiente se examina de la misma manera. Si la condición `WHEN` no es true, el valor de la expresión `CASE` es el resultado de la cláusula `ELSE`. Si se omite la cláusula `ELSE` y no se cumple ninguna condición, el resultado es `NULL`. - -## CAST - -`CAST` especifica una conversión de un tipo de datos a otro. - -### Sintaxis - -{{< code-block lang="sql" >}} -CAST(expresión COMO tipo) -{{< /code-block >}} - -No todos los tipos son convertibles de esta forma. - -DDSQL también admite la sintaxis de transmisión de Postgres: - -{{< code-block lang="sql" >}} -expression::type -{{< /code-block >}} - -Por ejemplo, `SELECT 1::text;`. - - -[1]: /es/ddsql_editor/reference/tags/ -[2]: https://www.postgresql.org/docs/current/functions-comparison.html \ No newline at end of file From a2173252f0e61dca120eb364eee59f4d5a254744 Mon Sep 17 00:00:00 2001 From: guacbot Date: Fri, 9 May 2025 15:26:38 +0100 Subject: [PATCH 07/29] Deleting translations of content/es/ddsql_editor/reference_tables.md --- content/es/ddsql_editor/reference_tables.md | 54 --------------------- 1 file changed, 54 deletions(-) delete mode 100644 content/es/ddsql_editor/reference_tables.md diff --git a/content/es/ddsql_editor/reference_tables.md b/content/es/ddsql_editor/reference_tables.md deleted file mode 100644 index 70d4cde0129ec..0000000000000 --- a/content/es/ddsql_editor/reference_tables.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -further_reading: -- link: /integrations/guide/reference-tables/ - tag: Documentación - text: Añadir metadatos personalizados con tablas de referencia -title: Tablas de referencia en DDSQL ---- - -# Información general - -Las tablas de referencia permiten combinar metadatos con información ya existente en Datadog. Estas tablas almacenan conjuntos predefinidos de información que se pueden citar fácilmente en las consultas, lo que reduce la complejidad y mejora el rendimiento de las consultas. Con DDSQL puedes consultar y unir tablas de referencia con otras tablas para ampliar tu información de análisis. - -Para obtener más información sobre cómo añadir tablas de referencia, consulta la [documentación Tablas de referencia][1]. - -## Consultar tablas de referencia - -Puedes consultar tablas de referencia directamente utilizando el Editor DDSQL. El objetivo de esta guía es mostrarte cómo puedes liberar todo el potencial de las tablas de referencia en tus consultas de datos. - -### Ejemplo de sintaxis de consulta - -Para consultar una tabla de referencia, puedes utilizar la siguiente sintaxis. Supongamos que la tabla de referencia se llama "test": - -```sql -SELECT * FROM reference_tables.test -``` - -Esta consulta recupera todos los datos de la tabla de referencia especificada. Modifica la consulta para incluir columnas o condiciones específicas, según sea necesario. - -### Unir datos - -Además de consultar tablas de referencia, también puedes unirlas a otras tablas disponibles. Al unir tablas de referencia, puedes: - -- Combinar datos de referencia con datos en tiempo real para mejorar tus informes y dashboards. -- Integrar datos estáticos y dinámicos para obtener análisis exhaustivos. - -El siguiente es un ejemplo de unión de una tabla de referencia con otra tabla: - -```sql -SELECT a.table_name, b.table.version -FROM reference_tables.test a - JOIN other_table b ON a.key = b.key -ORDER BY b.table_version DESC; -``` - -## Prácticas recomendadas - -Actualiza periódicamente las tablas de referencia para garantizar la exactitud de los datos. - -## Referencias adicionales - -{{< partial name="whats-next/whats-next.html" >}} - - -[1]: /es/integrations/guide/reference-tables/ \ No newline at end of file From 931b6d127776fc059d59d0fb534fabff0a69c2ec Mon Sep 17 00:00:00 2001 From: guacbot Date: Fri, 9 May 2025 21:58:48 +0100 Subject: [PATCH 08/29] Deleting translations of content/es/service_management/service_level_objectives/ootb_dashboard.md --- .../ootb_dashboard.md | 70 ------------------- 1 file changed, 70 deletions(-) delete mode 100644 content/es/service_management/service_level_objectives/ootb_dashboard.md diff --git a/content/es/service_management/service_level_objectives/ootb_dashboard.md b/content/es/service_management/service_level_objectives/ootb_dashboard.md deleted file mode 100644 index 5362421663c5c..0000000000000 --- a/content/es/service_management/service_level_objectives/ootb_dashboard.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -further_reading: -- link: service_management/service_level_objectives/ - tag: Documentación - text: Visión general de Objetivos de nivel de servicio (SLOs) -title: Dashboard de rendimiento de los SLOs para directivos ---- - -{{< jqmath-vanilla >}} - -## Información general - -El dashboard de resumen del rendimiento de los SLOs permite obtener vistas agregadas de los SLOs para ayudar a los directores ejecutivos a comprender de un solo vistazo la fiabilidad de tu organización. Con este dashboard predefinido puedes: - -- Personalizar tus agrupaciones de SLOs para que se basen en servicios, equipos, recorridos de usuarios o cualquier otra etiqueta (tag) que se haya añadido a tus SLOs. -- Utilizar una puntuación resumida, basada en el presupuesto de error restante de los SLOs subyacentes, para comprender el rendimiento de los SLOs en los diferentes grupos e identificar áreas de mejora. - -
El dashboard de resumen del rendimiento de los SLOs está en Vista previa.
- -Accede a tu dashboard de resumen del rendimiento de los SLOs predefinido filtrando por `SLO Performance Summary` en la consulta de búsqueda de la [**lista de dashboards**][1] o haciendo clic en el botón **Analytics** (Análisis) en la esquina superior derecha de la [página de estado de los SLOs][2]. - -{{< img src="service_management/service_level_objectives/ootb_dashboard/slo-ootb-dashboard.png" alt="Dashboard de SLOs predefinido por defecto por etiqueta de servicio" >}} - -## Interactuar con tu dashboard de resumen del rendimiento de los SLOs - -Por defecto, el dashboard de resumen del rendimiento de los SLOs se basa en la etiqueta de `service` añadida a tus SLOs. Esto te permite ver el rendimiento de los SLOs de tu organización por agrupaciones de servicios para entender qué servicios presentan un mejor o peor rendimiento. - -### Puntuación global - -El widget **Resumen de SLOs** en el dashboard predefinido incluye una "Puntuación". Fue diseñada como una métrica de resumen para que los directivos ejecutivos comprendan el rendimiento de un grupo de SLOs. La puntuación se calcula a partir del presupuesto de error medio restante de los SLOs subyacentes, que luego se asigna a una puntuación entre 0 y 100: - -- La puntuación se "aprueba" (verde/amarillo) cuando la mayoría de los SLOs **no** se incumplen y tienen un presupuesto de error restante. -- La puntuación se "desaprueba" (rojo) cuando muchos SLOs están fuera del presupuesto de error o unos pocos SLOs están demasiado fuera del presupuesto de error. -- Los SLOs con el estado "Sin datos" no se tienen en cuenta en la puntuación. - -#### Detalles del cálculo de la puntuación - -La puntuación se calcula del siguiente modo: -- Promediando el presupuesto de error restante de los SLOs (el presupuesto de error mínimo se establece en -200%, por lo que cualquier SLO con un presupuesto de error inferior se contará como -200% en el promedio). -- El presupuesto de error medio (entre -200 y 100) se asigna a una puntuación entre 0 y 100 -- El color y el estado de la puntuación se establecen en función de los siguientes umbrales. - -Ten en cuenta que un presupuesto de error medio restante del 0% corresponde a un valor de puntuación de 66,667. El estado y el color de la puntuación se basan en los siguientes umbrales: -- **Rojo:** 0 ≤ puntuación < 66,667 -- **Amarillo:** 66,667 ≤ puntuación < 80 -- **Verde:** 80 ≤ puntuación ≤ 100 - -### Personalizar tu dashboard de resumen del rendimiento de los SLOs - -Para personalizar tu dashboard de resumen del rendimiento de los SLOs, haz clic en **Configure** (Configurar) en el dashboard y selecciona **Clonar dashboard**. El dashboard por defecto está configurado basado en la etiqueta de `service` que se agregó a los SLOs. Puedes actualizar el dashboard para que se base en cualquier [etiqueta de SLO][3] siguiendo los siguientes pasos: - -- Actualiza la configuración de cada widget en el dashboard por defecto para utilizar tu etiqueta elegida, en lugar de `service`. -- Añade una [variable de plantilla][4] basada en tu etiqueta elegida (o sustituye la variable de plantilla `service` existente). - - -Por ejemplo, si ha añadiste una etiqueta `journey` a tus SLOs, puedes clonar el dashboard de resumen del rendimiento de los SLOs y personalizarlo para que se base en la etiqueta de `journey`: - -{{< img src="service_management/service_level_objectives/ootb_dashboard/slo-dashboard-flow.mp4" alt="Dashboard de SLOs predefinido por etiqueta de recorrido" video=true style="width:80%;" >}} - - - -## Referencias adicionales - -{{< partial name="whats-next/whats-next.html" >}} - - -[1]: https://app.datadoghq.com/dashboard/lists -[2]: https://app.datadoghq.com/slo -[3]: /es/service_management/service_level_objectives/#slo-tags -[4]: /es/dashboards/template_variables/#add-a-template-variable \ No newline at end of file From 200f203bf601a879dce0076fdb8e956ed960aee7 Mon Sep 17 00:00:00 2001 From: guacbot Date: Sat, 10 May 2025 00:16:22 +0100 Subject: [PATCH 09/29] Translated file updates --- .../synthetic-test-retries-monitor-status.md | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/content/ja/synthetics/guide/synthetic-test-retries-monitor-status.md b/content/ja/synthetics/guide/synthetic-test-retries-monitor-status.md index 1c38216c477f2..80d06683b6bca 100644 --- a/content/ja/synthetics/guide/synthetic-test-retries-monitor-status.md +++ b/content/ja/synthetics/guide/synthetic-test-retries-monitor-status.md @@ -12,44 +12,44 @@ title: Synthetic テストのリトライがモニターステータスにどの ## 概要 -To reduce alert fatigue, Synthetic tests can be retried when a test run fails. If you have configured a test to be retried on failures, this is a _fast retry_. +アラート疲れ (alert fatigue) を軽減するために、テスト実行が失敗した場合に Synthetic テストをリトライ (再試行) できます。失敗時のリトライを設定している場合、これを「高速リトライ (fast retry)」と呼びます。 -With a fast retry, Datadog runs a Synthetic test multiple times before transitioning the test's monitor to alert and sending you a notification. For more information about monitors associated with your Synthetic tests, see [Use Synthetic Test Monitors][3]. +高速リトライでは、Datadog はモニターをアラート状態に切り替えて通知を送信する前に、Synthetic テストを複数回実行します。Synthetic テストに関連付けられたモニターの詳細については、[Synthetic テストモニターの使用][3]を参照してください。 -{{< img src="synthetics/guide/synthetics_test_retries/fast_retries.png" alt="Failed test runs with fast retries" style="width:100%;">}} +{{< img src="synthetics/guide/synthetics_test_retries/fast_retries.png" alt="高速リトライを伴う失敗したテスト実行" style="width:100%;">}} -## Group evaluations +## グループ評価 -While fast retry results are used in the local group evaluation, only the final retry is taken into account in the total group evaluation. The original run and all intermediate retries are discarded from the evaluation. +高速リトライ結果はローカルグループ評価で使用されますが、最終的なリトライ結果のみが合計グループ評価に考慮されます。元のテスト実行と途中のリトライ結果は評価対象から除外されます。 -Local Group Evaluation -: Evaluation of the location status. +ローカルグループ評価 +: ロケーションステータスの評価 トータルグループ評価 : テストステータスの評価。 -A run that is still failing after it has reached the maximum number of retries is considered final, and this final result is taken into account in the total group evaluation. +設定した最大リトライ回数に達してもなおテストが失敗している場合、その結果が最終判定となり、合計グループ評価に反映されます。 -## Retries that overlap with other test runs +## 他のテストランとリトライが重なる場合 -In this example, a Synthetic test is scheduled to run every three minutes, and has a retry configured to a maximum of two times with a delay of two minutes. +以下の例では、Synthetic テストが 3 分ごとに実行され、リトライは最大 2 回まで、各リトライまでの待機時間を 2 分に設定しています。 -The evaluation only takes the final retry into account for the total group evaluation. +合計グループ評価では、最終的なリトライ結果のみが評価に考慮されます。 -When all retries fail: +全リトライが失敗した場合: -{{< img src="synthetics/guide/synthetics_test_retries/diagram_1.png" alt="A test run which was retried twice and failed on all retries, evaluated as a local group and as a total group" style="width:100%;">}} +{{< img src="synthetics/guide/synthetics_test_retries/diagram_1.png" alt="2 回リトライしてすべて失敗したテスト実行をローカルグループと合計グループで評価した図" style="width:100%;">}} -Or when a retry is successful: +リトライが成功した場合: {{< img src="synthetics/guide/synthetics_test_retries/diagram_2.png" alt="2 回リトライされ、3 回目のリトライで成功したテスト実行を、ローカルグループおよびトータルグループとして評価" style="width:100%;">}} -**Note:** Depending on what you set for the `minFailureDuration` and `minLocationsFailed` parameters, you may see different behavior. +**注:** `minFailureDuration` と `minLocationsFailed` のパラメータ設定によっては、異なる動作が見られる場合があります。 -## Timestamps +## タイムスタンプ -The system populates the timestamp for a final result with the time when the test was retried, not the time the test was originally scheduled. Results are considered at the timestamp when the test was started. Due to the test's execution time, there may be a small delay before the results become available for the evaluation. +最終結果のタイムスタンプには、テストがリトライされた時刻が使用され、元々テストがスケジュールされた時刻は使用されません。結果は、テストが開始された時点のタイムスタンプで評価されます。テストの実行時間のため、結果が評価に反映されるまでに若干の遅延が生じる場合があります。 ## 参考資料 From 7ca8b9c870de6e29047c2b1409c028ac31e34430 Mon Sep 17 00:00:00 2001 From: guacbot Date: Sat, 10 May 2025 02:16:24 +0100 Subject: [PATCH 10/29] Translated file updates --- data/api/v1/translate_tags.ja.json | 42 +++++++++++++++--------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/data/api/v1/translate_tags.ja.json b/data/api/v1/translate_tags.ja.json index 6a7c27c30c4d4..9b109b172361d 100644 --- a/data/api/v1/translate_tags.ja.json +++ b/data/api/v1/translate_tags.ja.json @@ -5,11 +5,11 @@ }, "aws-logs-integration": { "name": "AWS ログインテグレーション", - "description": "Datadog-AWS-Logs インテグレーションの構成は、Datadog API から直接行います。\n詳細については、[AWS インテグレーションのページ](https://docs.datadoghq.com/api/?lang=bash#integration-aws-logs)を参照してください。" + "description": "Datadog-AWS-Logs インテグレーションの構成は、Datadog API から直接行います。\n詳細については、[AWS インテグレーションのページ](https://docs.datadoghq.com/integrations/amazon_web_services/#log-collection)を参照してください。" }, "authentication": { "name": "Authentication", - "description": "Datadog の API に対するリクエストはすべて認証される必要があります。\nデータを書き込むリクエストにはレポートアクセスが必要で、`API key` が必要です。\nデータを読み取るリクエストにはフルアクセスが必要で、`application key` も必要です。\n\n**注:** すべての Datadog API クライアントは、デフォルトで Datadog US サイト API を使用するように構成されています。\nDatadog EU サイトを使用している場合は、環境変数 `DATADOG_HOST` を `https://api.datadoghq.eu`に設定するか、クライアントを作成するときにこの値を直接オーバーライドします。\n\n[アカウントの API とアプリケーションキーを管理します](https://app.datadoghq.com/account/settings#api)。" + "description": "Datadog の API に対するリクエストはすべて認証される必要があります。\nデータを書き込むリクエストにはレポートアクセスが必要で、`API key` が必要です。\nデータを読み取るリクエストにはフルアクセスが必要で、`application key` も必要です。\n\n**注:** すべての Datadog API クライアントは、デフォルトで Datadog US サイト API を使用するように構成されています。\nDatadog EU サイトを使用している場合は、環境変数 `DATADOG_HOST` を `https://api.datadoghq.eu` に設定するか、クライアントを作成するときにこの値を直接オーバーライドします。\n\nDatadog で[アカウントの API およびアプリケーションキーを管理](https://app.datadoghq.com/organization-settings/)し、ドキュメントの [API およびアプリケーションキーのページ](https://docs.datadoghq.com/account_management/api-app-keys/)を参照してください。" }, "azure-integration": { "name": "Azure インテグレーション", @@ -21,19 +21,19 @@ }, "dashboards": { "name": "ダッシュボード", - "description": "API を介してすべてのダッシュボードを簡単に整理、検索、およびチームや組織と共有できます。" + "description": "API を使用して、ダッシュボードおよび共有ダッシュボードへのアクセスを管理します。詳細については、[ダッシュボードページ](https://docs.datadoghq.com/dashboards/)をご覧ください。" }, "downtimes": { "name": "ダウンタイム", - "description": "[ダウンタイム設定](https://docs.datadoghq.com/monitors/notify/downtimes)を使用すると、アラートからいくつかのスコープをグローバルに除外することができ、モニター通知をより詳細に制御できます。ダウンタイム設定は、開始時間と終了時間を指定してスケジューリングされ、指定された Datadog タグに関連するすべてのアラートの発生を抑止します。" + "description": "[ダウンタイム](https://docs.datadoghq.com/monitors/notify/downtimes)を使用すると、アラート通知をより柔軟に制御でき、特定のスコープをグローバルにアラート対象から除外できます。開始時刻と終了時刻を設定できるダウンタイムによって、指定した Datadog タグに関連するすべてのアラートが抑制されます。\n\n**注:** `curl` コマンドでは [URL エンコード](https://curl.se/docs/url-syntax.html)が必要です。" }, "embeddable-graphs": { "name": "埋め込み可能なグラフ", - "description": "API を使用して埋め込み可能なグラフを操作します。" + "description": "API を使用して、埋め込み可能なグラフを管理します。詳細については、[テンプレート変数による埋め込み可能なグラフ](https://docs.datadoghq.com/dashboards/guide/embeddable-graphs-with-template-variables/)をご覧ください。" }, "events": { "name": "イベント", - "description": "イベントサービスを使用すると、プログラムでイベントをイベントストリームにポストしたり、イベントストリームから取得することができます。イベントは 4000 文字に制限されています。4000 文字を超えるメッセージを含むイベントが送信された場合は、最初の 4000 文字だけが表示されます。" + "description": "Event Management API を使用すると、Events Explorer へイベントをプログラムで送信したり、Events Explorer からイベントを取得したりできます。詳細は [Event Management ページ](https://docs.datadoghq.com/service_management/events/)を参照してください。\n \n**2025 年 3 月 1 日からの Datadog モニターイベント `aggregation_key` の変更:** `aggregation_key` はこれまでモニター ID ごとに一意でしたが、2025 年 3 月 1 日以降はモニターグループも含まれ、*モニター ID とモニターグループ* の組み合わせで一意になります。ダッシュボードクエリや Event API で `aggregation_key` を使用している場合は、`@monitor.id` への移行が必要です。ご不明点があれば[サポート](https://www.datadoghq.com/support/)までお問い合わせください。" }, "gcp-integration": { "name": "GCP インテグレーション", @@ -41,7 +41,7 @@ }, "hosts": { "name": "ホスト", - "description": "Datadog でライブホストに関する情報を取得します。" + "description": "Datadog でインフラストラクチャーホストの情報を取得し、ホストからの通知をミュートまたはミュート解除します。詳細については、[インフラストラクチャーページ](https://docs.datadoghq.com/infrastructure/)をご覧ください。" }, "ip-ranges": { "name": "IP 範囲", @@ -53,23 +53,23 @@ }, "logs": { "name": "ログ", - "description": "ログを検索して、HTTP で Datadog プラットフォームに送信します。" + "description": "ログを検索し、HTTP 経由で Datadog プラットフォームに送信します。詳細については、[Log Management ページ](https://docs.datadoghq.com/logs/)をご覧ください。" }, "logs-indexes": { "name": "ログインデックス", - "description": "[ログインデックス](https://docs.datadoghq.com/logs/indexes/)のコンフィギュレーションを管理します。\nこのエンドポイントとやり取りするには、管理者権限を持つ API とアプリケーションキーが必要です。" + "description": "[ログインデックス](https://docs.datadoghq.com/logs/indexes/)の設定を管理します。" }, "logs-pipelines": { "name": "ログパイプライン", - "description": "パイプラインとプロセッサは受信ログを操作し、クエリを簡単にするためにそれを解析して構造化属性に変換します。\n\n- 現在ウェブ UI で構成されているパイプラインとプロセッサの一覧については、[パイプラインコンフィギュレーションページ](https://app.datadoghq.com/logs/pipelines)を参照してください。\n\n- プロセッサに関する追加の API 関連情報は、[プロセッサのドキュメント](https://docs.datadoghq.com/logs/log_configuration/processors/?tab=api#lookup-processor)にあります。\n\n- パイプラインの詳細については、[パイプラインのドキュメント]((https://docs.datadoghq.com/logs/log_configuration/pipelines)を参照してください。\n\n**注:**\n\nこれらのエンドポイントは管理者ユーザーのみが利用できます。\n管理者が作成したアプリケーションキーを使用してください。\n\n**Grok パース規則は JSON 出力に影響を与える場合があり、\nリクエスト内で使用する前に、返されたデータが構成済みである必要があります。**\nたとえば、別のリクエスト本文のリクエスト\nから返されたデータを使用していて、スペースに `\\s` のような\n正規表現パターンを使用するパース規則がある場合、\nすべてのエスケープしたスペースを `%{space}` と構成して\n本文データに使用する必要があります。" + "description": "パイプラインとプロセッサは受信ログを解析して変換し、クエリしやすい構造化属性にします。\n\n- Web UI で現在設定されているパイプラインとプロセッサの一覧は[パイプライン設定ページ](https://app.datadoghq.com/logs/pipelines)を参照してください。\n\n- プロセッサに関する API 情報は[プロセッサのドキュメント](https://docs.datadoghq.com/logs/log_configuration/processors/?tab=api#lookup-processor)を参照してください。\n\n- パイプラインの詳細は[パイプラインのドキュメント](https://docs.datadoghq.com/logs/log_configuration/pipelines)を参照してください。\n\n**注:**\n\n**Grok 解析ルールは JSON 出力に影響する場合があり、リクエストで使用する前に返却データの調整が必要になることがあります。**\nたとえば、あるリクエストの戻り値を別のリクエストのボディに使用する際に、`\\s` のような空白を表す正規表現を使用する解析ルールがある場合は、ボディデータ内のエスケープされた空白を `%{space}` に置き換える必要があります。" }, "metrics": { "name": "メトリクス", - "description": "メトリクスエンドポイントでは、次のことができます。\n\n- メトリクスデータを投稿して Datadog のダッシュボードにグラフ化できるようにする\n- 任意の期間のメトリクスをクエリする\n- メトリクスのタグコンフィギュレーションを変更する\n- メトリクスのタグとボリュームを確認する\n\n**注**: グラフには設定された数のポイントのみを含めることができ、\nメトリクスが表示されるタイムフレームが長くなると、\nポイント間の集計が発生してその設定された数を下回ります。\n\n`manage_tags` を Post、Patch、Delete する API メソッドは\n`Manage Tags for Metrics` アクセス許可を持つユーザーのみが実行できます。" + "description": "メトリクスエンドポイントでは、次のことができます。\n\n- メトリクスデータを投稿して Datadog のダッシュボードにグラフ化できるようにする\n- 任意の期間のメトリクスをクエリする\n- メトリクスのタグ構成を変更する\n- メトリクスのタグとボリュームを確認する\n\n**注**: グラフには設定された数のポイントのみを含めることができ、\nメトリクスが表示される期間が長くなると、\nポイント間の集計が発生してその設定された数を下回ります。\n\n`manage_tags` を Post、Patch、Delete する API メソッドは\n`Manage Tags for Metrics` 権限を持つユーザーのみが実行できます。\n\n詳しくは[メトリクスページ](https://docs.datadoghq.com/metrics/)をご覧ください。" }, "monitors": { "name": "モニター", - "description": "[モニター](https://docs.datadoghq.com/monitors)を使用すると、気になるメトリクスまたはチェックを監視して、定義されたしきい値を超えたときにチームに通知することができます。\n詳しくは、[モニターの作成](https://docs.datadoghq.com/monitors/create/types/)ページを参照してください。" + "description": "[モニター](https://docs.datadoghq.com/monitors)を利用すると、重要なメトリクスやチェックを監視し、設定したしきい値を超えた際にチームへ通知できます。\n\n詳細は[モニターの作成](https://docs.datadoghq.com/monitors/create/types/)を参照してください。\n\n**注:** `curl` コマンドでは [URL エンコード](https://curl.se/docs/url-syntax.html)が必要です。" }, "notebooks": { "name": "ノートブック", @@ -85,23 +85,23 @@ }, "screenboards": { "name": "スクリーンボード", - "description": "このエンドポイントは旧バージョンです。代わりに、[新しいダッシュボードエンドポイント](https://docs.datadoghq.com/api/#dashboards)を使用してください。" + "description": "このエンドポイントは廃止予定です。代わりに [新しいダッシュボードエンドポイント](https://docs.datadoghq.com/api/latest/dashboards/)を使用してください。" }, "security-monitoring": { "name": "セキュリティモニタリング", - "description": "信号を生成し、生成された信号を一覧表示するための検出ルール。" + "description": "セキュリティ ルール、シグナル、フィルターなどを作成および管理します。詳細については、[Datadog Security ページ](https://docs.datadoghq.com/security/)をご覧ください。" }, "service-checks": { "name": "サービスのチェック", - "description": "サービスチェックエンドポイントを使用すると、モニターで使用するためにチェックステータスを投稿できます。\nサービスチェックメッセージは 500 文字に制限されています。\n500 文字を超えるメッセージでチェックが投稿された場合、最初の 500 文字のみが表示されます。\nメッセージは、Critical または Warning のステータスのチェックに制限されます。\n\n- [サービスチェックモニターの詳細をご覧ください。][1]\n- [プロセスチェックモニターの詳細をご覧ください。][2]\n- [ネットワークチェックモニターの詳細をご覧ください。][3]\n- [カスタムチェックモニターの詳細をご覧ください。][4]\n- [サービスチェックとステータスコードの詳細をご覧ください。][5]\n\n[1]: https://docs.datadoghq.com/monitors/create/types/host/?tab=checkalert\n[2]: https://docs.datadoghq.com/monitors/create/types/process_check/?tab=checkalert\n[3]: https://docs.datadoghq.com/monitors/create/types/network/?tab=checkalert\n[4]: https://docs.datadoghq.com/monitors/create/types/custom_check/?tab=checkalert\n[5]: https://docs.datadoghq.com/developers/service_checks/" + "description": "サービスチェックエンドポイントを使用すると、モニターで使用するためにチェックステータスを投稿できます。\nサービスチェックメッセージは 500 文字に制限されています。\n500 文字を超えるメッセージでチェックが投稿された場合、最初の 500 文字のみが表示されます。\nメッセージは、Critical または Warning のステータスのチェックに制限されます。OK ステータスのチェックにはメッセージは表示されません。\n\n- [サービスチェックモニターの詳細をご覧ください][1]。\n- [プロセスチェックモニターの詳細をご覧ください][2]。\n- [ネットワークモニターの詳細をご覧ください][3]。\n- [カスタムチェックモニターの詳細をご覧ください][4]。\n- [サービスチェックとステータスコードの詳細をご覧ください][5]。\n\n[1]: https://docs.datadoghq.com/monitors/types/service_check/\n[2]: https://docs.datadoghq.com/monitors/create/types/process_check/?tab=checkalert\n[3]: https://docs.datadoghq.com/monitors/create/types/network/?tab=checkalert\n[4]: https://docs.datadoghq.com/monitors/create/types/custom_check/?tab=checkalert\n[5]: https://docs.datadoghq.com/developers/service_checks/" }, "service-dependencies": { "name": "サービスの依存関係", - "description": "APM サービスマップ API。詳細については、[サービスマップのドキュメント](https://docs.datadoghq.com/tracing/visualization/services_map/)にアクセスしてください。" + "description": "APM サービスマップ API。詳細については、[サービスマップページ](https://docs.datadoghq.com/tracing/visualization/services_map/)をご覧ください。" }, "service-level-objective-corrections": { "name": "Service Level Objective Corrections", - "description": "SLO ステータス補正を行うことで、特定の期間に発生しうる SLO のステータスとエラー予算への\n悪影響を回避することができます。ステータス補正は計画済みのメンテナンスウィンドウ、営業外の時間、\nまたはその他深刻な問題に相当しない期間の削除など、\nさまざまな目的で使用できます。" + "description": "SLO ステータス補正を行うことで、特定の期間に発生しうる SLO のステータスとエラー予算への\n悪影響を回避することができます。ステータス補正は計画済みのメンテナンスウィンドウ、営業外の時間、\nまたはその他深刻な問題に相当しない期間の削除など、\nさまざまな目的で使用できます。詳しくは [SLO ステータス補正](https://docs.datadoghq.com/service_management/service_level_objectives/#slo-status-corrections)をご覧ください。" }, "service-level-objectives": { "name": "サービスレベル目標", @@ -121,15 +121,15 @@ }, "tags": { "name": "タグ", - "description": "タグエンドポイントを使用すると、ホストにタグを割り当てることができます。\n例: `role:database`。これらのタグは、ホストから送信されるすべてのメトリクスに適用されます。タグを取得して特定のホストに適用するときは、名前でホストを参照します (`yourhost.example.com`)。\n\nタグを担当するインフラストラクチャーのコンポーネントはソースによって識別されます。たとえば、有効なソースには、nagios、hudson、jenkins、users、feed、chef、puppet、git、bitbucket、fabric、capistrano などがあります。\n\nタグの詳細は専用の[ドキュメントページ](https://docs.datadoghq.com/tagging)をご覧ください。" + "description": "タグエンドポイントを使用すると、ホストにタグを割り当てることができます。\n例: `role:database`。これらのタグは、ホストから送信されるすべてのメトリクスに適用されます。タグを取得して特定のホストに適用するときは、名前でホストを参照します (`yourhost.example.com`)。\n\nタグを担当するインフラストラクチャーのコンポーネントはソースによって識別されます。たとえば、有効なソースには、nagios、hudson、jenkins、users、feed、chef、puppet、git、bitbucket、fabric、capistrano などがあります。\n\nタグの詳細は[タグの概要](https://docs.datadoghq.com/getting_started/tagging/)をご覧ください。" }, "timeboards": { "name": "タイムボード", - "description": "このエンドポイントは旧バージョンです。代わりに、[新しいダッシュボードエンドポイント](https://docs.datadoghq.com/api/#dashboards)を使用してください。" + "description": "このエンドポイントは廃止予定です。代わりに [新しいダッシュボードエンドポイント](https://docs.datadoghq.com/api/latest/dashboards/)を使用してください。" }, "usage-metering": { "name": "使用料のメータリング", - "description": "使用量計測 API を使用すると、Datadog の複数のファセットで 1 時間ごと、1 日ごと、および 1 か月ごとの使用量を取得できます。\nこの API は、すべての Pro および Enterprise のお客様が利用できます。\n使用量にアクセスできるのは[親レベルの組織](https://docs.datadoghq.com/account_management/multi_organization/)のみです。\n\n**注**: 使用量データは、発生してから最大 72 時間遅れます。\n15 か月間保持されます。\n\n1 回のリクエストで、複数組織の 1 時間単位の利用データを最大 24 時間分、1 組織の 1 時間単位の利用データを最大 2 か月分取得することができます。" + "description": "使用量計測 API を使用すると、Datadog の多面的な使用量を 1 時間毎、1 日毎、1 か月毎に取得することができます。この API は、Pro と Enterprise のすべてのお客様にご利用いただけます。**注**: 使用量データは、発生から最大 72 時間遅延します。15 か月間保持されます。1 回のリクエストで、複数組織の最大 24 時間分の 1 時間ごとの使用量データ、および単一組織の最大 2 か月分の 1 時間ごとの使用量データを取得できます。詳細については、[使用量の詳細ドキュメント](https://docs.datadoghq.com/account_management/billing/usage_details/)をご覧ください。" }, "users": { "name": "ユーザー", @@ -137,6 +137,6 @@ }, "webhooks-integration": { "name": "Webhook インテグレーション", - "description": "Datadog-Webhooks インテグレーションの構成は、Datadog API から直接行います。\nDatadog-Webhooks インテグレーションの詳細については、[インテグレーションページ](https://docs.datadoghq.com/integrations/webhooks)を参照してください。" + "description": "Datadog API を使用して、Datadog-Webhooks インテグレーションを直接構成します。\n詳細については、[Webhooks インテグレーションページ](https://docs.datadoghq.com/integrations/webhooks)をご覧ください。" } } \ No newline at end of file From 03b9177d83a06c089043b8f1ccc94e5c380569aa Mon Sep 17 00:00:00 2001 From: guacbot Date: Sun, 11 May 2025 06:16:25 +0100 Subject: [PATCH 11/29] Translated file updates --- .../integrations/oci_service_connector_hub.md | 110 ++++++++++++++++++ 1 file changed, 110 insertions(+) create mode 100644 content/ja/integrations/oci_service_connector_hub.md diff --git a/content/ja/integrations/oci_service_connector_hub.md b/content/ja/integrations/oci_service_connector_hub.md new file mode 100644 index 0000000000000..bce7e1cc47885 --- /dev/null +++ b/content/ja/integrations/oci_service_connector_hub.md @@ -0,0 +1,110 @@ +--- +app_id: oci-service-connector-hub +app_uuid: c7144268-2a76-4578-964d-5e59f7619d8d +assets: + integration: + auto_install: true + events: + creates_events: false + metrics: + check: + - oci.service_connector_hub.bytes_read_from_source + - oci.service_connector_hub.bytes_read_from_task + - oci.service_connector_hub.bytes_written_to_target + - oci.service_connector_hub.bytes_written_to_task + - oci.service_connector_hub.data_freshness + - oci.service_connector_hub.errors_at_source + - oci.service_connector_hub.errors_at_target + - oci.service_connector_hub.errors_at_task + - oci.service_connector_hub.latency_at_source + - oci.service_connector_hub.latency_at_target + - oci.service_connector_hub.latency_at_task + - oci.service_connector_hub.messages_read_from_source + - oci.service_connector_hub.messages_read_from_task + - oci.service_connector_hub.messages_written_to_target + - oci.service_connector_hub.messages_written_to_task + - oci.service_connector_hub.service_connector_hub_errors + metadata_path: metadata.csv + prefix: oci. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 39303353 + source_type_name: OCI サービスコネクタハブ +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com (日本語対応) + support_email: help@datadoghq.com +categories: +- ネットワーク +- クラウド +- oracle +- モニター +custom_kind: インテグレーション +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: oci_service_connector_hub +integration_id: oci-service-connector-hub +integration_title: OCI サービスコネクタハブ +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: oci_service_connector_hub +public_title: OCI サービスコネクタハブ +short_description: OCI Service Connector Hub は OCI サービス間でデータを接続およびルーティングし、クラウド運用を効率化します。 +supported_os: [] +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Network + - Category::Cloud + - Category::Oracle + - Category::Metrics + - Offering::Integration + configuration: README.md#Setup + description: OCI Service Connector Hub は OCI サービス間でデータを接続およびルーティングし、クラウド運用を効率化します。 + media: [] + overview: README.md#Overview + support: README.md#Support + title: OCI サービスコネクタハブ +--- + + + + +## 概要 + +Connector Hub はクラウドエンジニアが Oracle Cloud Infrastructure (OCI) サービス間、また OCI からサードパーティサービスへのデータを管理および移動できるよう支援します。 + +このインテグレーションでは、[oci_service_connector_hub][1] ネームスペースからメトリクスとタグを収集することで、Connector Hub のスループット、レイテンシ、エラーを監視しアラートできます。 + +## セットアップ + +### インストール + +[Oracle Cloud Infrastructure][2] インテグレーションをセットアップしたら、上記で言及したネームスペースが [Connector Hub][3] に含まれていることを確認してください。 + +## 収集データ + +### メトリクス +{{< get-metrics-from-git "oci_service_connector_hub" >}} + + +### サービスチェック + +OCI Service Connector Hub にはサービスチェックが含まれていません。 + +### イベント + +OCI Service Connector Hub にはイベントが含まれていません。 + +## トラブルシューティング + +ご不明な点は、[Datadog のサポートチーム][5]までお問い合わせください。 + +[1]: https://docs.oracle.com/en-us/iaas/Content/connector-hub/metrics-reference.htm +[2]: https://docs.datadoghq.com/ja/integrations/oracle_cloud_infrastructure/ +[3]: https://cloud.oracle.com/connector-hub/service-connectors +[4]: https://github.com/DataDog/integrations-internal-core/blob/main/oci_service_connector_hub/metadata.csv +[5]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file From 81479b6de1685c9d56557241f2b513d0ec919800 Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 02:16:24 +0100 Subject: [PATCH 12/29] Translated file updates --- .../save-cpu-in-production-with-go-pgo.md | 65 +++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 content/ja/profiler/guide/save-cpu-in-production-with-go-pgo.md diff --git a/content/ja/profiler/guide/save-cpu-in-production-with-go-pgo.md b/content/ja/profiler/guide/save-cpu-in-production-with-go-pgo.md new file mode 100644 index 0000000000000..97e8b0731b5ef --- /dev/null +++ b/content/ja/profiler/guide/save-cpu-in-production-with-go-pgo.md @@ -0,0 +1,65 @@ +--- +further_reading: +- link: /profiler + tag: ドキュメント + text: Datadog Continuous Profiler +- link: /profiler/compare_profiles/ + tag: ドキュメント + text: プロファイルの比較 +title: Go - プロファイルガイド最適化 (PGO) で本番環境の CPU 使用量を最大 14% 削減 +--- + +## 概要 + +[Go 1.21][1] から、Go コンパイラは profile-guided optimization (PGO) をサポートしています。 + +PGO は、本番ワークロードの CPU プロファイルから特に高負荷と判定されたコードに対して、追加の最適化を適用します。これは [Datadog Go Continuous Profiler][2] と互換性があり、本番ビルドで使用できます。 + +## PGO の仕組み + +PGO の動作に関する主なポイントは以下のとおりです。 + +- PGO を有効にして Go プログラムをビルドすると、コンパイラは `default.pgo` という名前の pprof CPU プロファイルを探し、それを使用してより最適化されたバイナリを生成します。 +- 典型的なプログラムでは、最適化後に CPU 使用時間が 2～14% 程度削減されると想定されます。PGO は現在も積極的に開発が進められており、将来的にはより大きな CPU 削減が期待されます。Datadog はこの取り組みを[積極的にサポートしています][3]。 +- PGO では、代表的なプロファイルを使用することで最良の結果が得られます。ただし、代表的でないプロファイルや古いプロファイル (ソフトウェアの以前のバージョンから取得したもの) を使用しても、PGO を使用しない場合より遅くなることはないと想定されています。 +- PGO 最適化済みアプリケーションから取得したプロファイルを使用しても、最適化や逆最適化が繰り返されるような「最適化サイクル」は発生しないと想定されています。これは反復的安定性 (iterative stability) と呼ばれます。 + +詳細は、[Go PGO ドキュメント][4]を参照してください。 + +## PGO の有効化 + +PGO は標準の Go コンパイラオプションで、Datadog からダウンロードしたプロファイルを手動で使用することも可能です。Datadog は、`datadog-pgo` というツールを用意しており、最新かつ最も代表的なプロファイルを使用してすべてのサービスで PGO を有効化するのに役立ちます。 + +`datadog-pgo` ツールを使った PGO の有効化手順 + +1. [API とアプリケーションキー][5] に記載のとおり、少なくとも `continuous_profiler_pgo_read` スコープを付与した API キーとアプリケーションキーを作成します。 +2. `DD_API_KEY`、`DD_APP_KEY`、`DD_SITE` を CI プロバイダーのシークレット環境変数機能で設定します。 +3. ビルドステップの前に `datadog-pgo` を実行します。 + 例えば、`prod` 環境で動作する `foo` サービスがあり、そのメインパッケージが `./cmd/foo` にある場合は、ビルドステップに以下のように追加します。 + + ``` + go run github.com/DataDog/datadog-pgo@latest "service:foo env:prod" ./cmd/foo/default.pgo + ``` + +Go ツールチェーンはメインパッケージ内にある `default.pgo` を自動的に読み込むため、`go build` ステップを変更する必要はありません。 + +詳しくは [datadog-pgo GitHub リポジトリ][6]を参照してください。 + +## PGO が有効になっているかの確認 + +PGO が有効になっているかを確認するには、[pgo タグが true に設定されていない Go プロファイルを検索][7]します。 + +`pgo` タグは dd-trace-go 1.61.0 で実装されたため、このバージョンより前のプロファイルでは `pgo:false` は表示されません。 + + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://tip.golang.org/doc/go1.21 +[2]: /ja/profiler/enabling/go +[3]: https://github.com/golang/go/issues/65532 +[4]: https://go.dev/doc/pgo +[5]: /ja/account_management/api-app-keys +[6]: https://github.com/DataDog/datadog-pgo?tab=readme-ov-file#getting-started +[7]: https://app.datadoghq.com/profiling/explorer?query=runtime%3Ago%20-pgo%3Atrue%20&viz=stream \ No newline at end of file From f2200866153104f61f0dcb821d59fba74fe527fb Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 08:16:25 +0100 Subject: [PATCH 13/29] Translated file updates From d0305da4f7aabffe3a28e07a0687ad81e2755c78 Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 10:16:32 +0100 Subject: [PATCH 14/29] Translated file updates --- .../ko/agent/troubleshooting/debug_mode.md | 71 ++--------- content/ko/integrations/sedai.md | 120 ++++++++++++++++++ 2 files changed, 131 insertions(+), 60 deletions(-) create mode 100644 content/ko/integrations/sedai.md diff --git a/content/ko/agent/troubleshooting/debug_mode.md b/content/ko/agent/troubleshooting/debug_mode.md index 10677f3618351..76ebaec4464ce 100644 --- a/content/ko/agent/troubleshooting/debug_mode.md +++ b/content/ko/agent/troubleshooting/debug_mode.md @@ -4,15 +4,15 @@ aliases: - /ko/agent/faq/agent-5-container-more-log further_reading: - link: /agent/troubleshooting/send_a_flare/ - tag: Agent 트러블슈팅 + tag: 설명서 text: Agent Flare 보내기 - link: /agent/troubleshooting/agent_check_status/ - tag: Agent 트러블슈팅 + tag: 설명서 text: Agent 점검의 상태 파악하기 title: 디버그 모드 --- -## Agent +## 개요 Agent의 로그 레벨 설정은 기본적으로 `INFO`입니다. 그러나 로그 레벨을 `DEBUG`로 설정하여 로그에서 더 많은 정보를 알아볼 수도 있습니다. @@ -20,9 +20,6 @@ Agent의 로그 레벨 설정은 기본적으로 `INFO`입니다. 그러나 로 Agent 전체 디버그 모드를 활성화하는 방법은 다음과 같습니다. -{{< tabs >}} -{{% tab "Agent v6 & v7" %}} - 1. 로컬 `datadog.yaml` 파일을 수정하세요. 사용하는 OS에 맞게 구체적인 안내를 받으려면 [Agent 주요 설정 파일][1]을 참조하시기 바랍니다. 2. `# log_level: INFO`를 `log_level: DEBUG`로 치환합니다(`#`을 삭제해 라인의 코멘트를 해제하세요). @@ -31,70 +28,19 @@ Agent 전체 디버그 모드를 활성화하는 방법은 다음과 같습니 4. 몇 분 기다리시면 로그가 생성됩니다. OS에 맞는 안내를 확인하려면 [Agent 로그 파일][3]을 참조하세요. -[1]: /ko/agent/guide/agent-configuration-files/#agent-main-configuration-file -[2]: /ko/agent/guide/agent-commands/#restart-the-agent -[3]: /ko/agent/guide/agent-log-files/ -{{% /tab %}} -{{% tab "Agent v5" %}} - -1. 로컬 `datadog.conf` 파일을 수정하세요. 사용하는 OS에 맞게 구체적인 안내를 받으려면 [Agent 주요 설정 파일][1]을 참조하시기 바랍니다. - -2. `# log_level: INFO`를 `log_level: DEBUG`로 치환합니다(`#`을 삭제해 라인의 코멘트를 해제하세요). - -3. Datadog Agent를 재시작하세요. OS에 맞게 구체적인 안내를 확인하려면 [Agent 명령어][2]를 참조하시기 바랍니다. - -4. 몇 분 기다리시면 로그가 생성됩니다. OS에 맞는 안내를 확인하려면 [Agent 로그 파일][3]을 참조하세요. - -[1]: /ko/agent/guide/agent-configuration-files/?tab=agentv5#agent-main-configuration-file -[2]: /ko/agent/guide/agent-commands/?tab=agentv5#restart-the-agent -[3]: /ko/agent/guide/agent-log-files/?tab=agentv5 -{{% /tab %}} -{{< /tabs >}} - ## 컨테이너화 Agent -{{< tabs >}} -{{% tab "Agent v6 & v7" %}} - 컨테이너 Agent에서 디버그 모드를 활성화하려면 Agent 부팅 시 `DD_LOG_LEVEL=debug`를 사용하세요. Agent v6.19/ v7.19 이상의 버전에서는 다음을 사용하여 런타임에서 Agent 로그 레벨을 설정할 수 있습니다. -``` -agent config set log_level debug -``` - -전용 컨테이너에 trace-agent가 있는 경우, Agent 컨테이너에서 했던 것처럼 런타임에서 trace-agent 컨테이너용 로그 레벨을 변경할 수 **없습니다**. 전용 trace-agent 컨테이너의 경우 `dd_log_level` 변수를 `debug`로 바꾸고 재배포해야 합니다. - -{{% /tab %}} -{{% tab "Agent v5" %}} - -컨테이너에서 실행되는 Agent는 `service datadog-agent restart`(또는 이와 유사한 기능)으로 재시작할 수 없습니다. 도커(Docker)에서 컨테이너를 삭제하기 때문입니다. Supervisor를 사용해 컨테이너화 Agent를 재시작하세요. - -```text -/opt/datadog-agent/bin/supervisorctl -c /etc/dd-agent/supervisor.conf restart all -``` - -다음의 명령어는 디버그 로깅, Agent 재시작, 60초 대기, 이후 Flare 전송을 순서대로 활성화합니다. - ```shell -sed -i '/\[Main\]/a LOG_LEVEL=DEBUG' /etc/dd-agent/datadog.conf -/opt/datadog-agent/bin/supervisorctl -c /etc/dd-agent/supervisor.conf restart all -sleep 60 -/etc/init.d/datadog-agent flare -``` - -디버그 로그를 비활성화하려면 다음을 사용하세요. - -```shell -sed -i '/LOG_LEVEL=DEBUG/d' /etc/dd-agent/datadog.conf -/opt/datadog-agent/bin/supervisorctl -c /etc/dd-agent/supervisor.conf restart all +agent config set log_level debug ``` -또는 컨테이너를 재시작해도 됩니다. +트레이스-에이전트 컨테이너의 로그 레벨은 에이전트 컨테이너에서 했던 것처럼 런타임에서 변경할 수 **없습니다**. 전용 트레이스-에이전트 컨테이너의 경우 `DD_LOG_LEVEL` 변수를 `debug`로 설정한 후 재배포해야 합니다. -{{% /tab %}} -{{< /tabs >}} +[**Helm**][4]을 사용하는 경우 `datadog-values.yaml` 파일에서 `logLevel: INFO`를 `logLevel: DEBUG`로 변경하고 다시 배포합니다. ## Agent 로그 레벨 @@ -115,3 +61,8 @@ sed -i '/LOG_LEVEL=DEBUG/d' /etc/dd-agent/datadog.conf ## 참고 자료 {{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/agent/configuration/agent-configuration-files/#agent-main-configuration-file +[2]: /ko/agent/configuration/agent-commands/#restart-the-agent +[3]: /ko/agent/configuration/agent-log-files/ +[4]: https://github.com/DataDog/helm-charts/blob/637472f105f42e8b444981ea2a38e955161c8e3a/charts/datadog/values.yaml#L125 \ No newline at end of file diff --git a/content/ko/integrations/sedai.md b/content/ko/integrations/sedai.md new file mode 100644 index 0000000000000..f7e790b54b1c4 --- /dev/null +++ b/content/ko/integrations/sedai.md @@ -0,0 +1,120 @@ +--- +app_id: sedai +app_uuid: fa7de455-fef8-4cb2-af30-9baa50e351f2 +assets: + dashboards: + Sedai Overview: assets/dashboards/sedai_overview.json + integration: + auto_install: true + configuration: {} + events: + creates_events: false + metrics: + check: [] + metadata_path: metadata.csv + prefix: sedai. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10249 + source_type_name: Sedai +author: + homepage: https://github.com/DataDog/integrations-extras + name: Sedai + sales_email: praveen.prakash@sedai.io + support_email: praveen.prakash@sedai.io +categories: +- 자동화 +- cloud +- 비용 관리 +- 알림 +- orchestration +- 프로비저닝 +custom_kind: integration +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/sedai/README.md +display_on_public_website: true +draft: false +git_integration_title: sedai +integration_id: sedai +integration_title: Sedai +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: sedai +public_title: Sedai +short_description: 클라우드 애플리케이션을 지능적으로 관리하는 자율 플랫폼 +supported_os: +- 리눅스 +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Automation + - "\b카테고리::클라우드" + - Category::Cost Management + - Category::Notifications + - Category::Orchestration + - 카테고리::프로비저닝 + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - 제공::통합 + configuration: README.md#Setup + description: 클라우드 애플리케이션을 지능적으로 관리하는 자율 플랫폼 + media: [] + overview: README.md#Overview + support: README.md#Support + title: Sedai +--- + + +## 개요 + +Sedai는 프로덕션을 선제적으로 관리하여 환경 문제를 예방하고 가용성, 성능 및 클라우드 비용을 개선하는 자율 클라우드 플랫폼입니다. SRE를 위한 지능형 자동 조종 장치인 Sedai는 모니터링 데이터를 독립적으로 감지, 우선순위를 지정 및 분석하여 임계값 없이 안전하고 자율적으로 프로덕션에서 작동합니다. + +이 통합을 활성화하면 Datadog 알림에서 Sedai가 프로덕션 환경에서 자율적으로 실행하는 작업에 관한 정보를 받을 수 있습니다. + +### 작동 방식 + +* **에이전트 없이 사용 가능:** 클라우드 계정에 원활하게 연결하여 프로덕션 환경을 자동으로 검색하고 이해합니다. + +* **무료 구성:** Datadog API 에 쉽게 연결하여 메트릭 행동을 지능적으로 식별하고 우선순위를 정해 학습합니다. + +* **선제적인 조치 조치:** 사용자를 대신해 프로덕션 환경에서 안전하게 작업하여 리소스가 가용성 문제를 방지하고 항상 최적으로 실행되도록 합니다. + +## 설정 + +Sedai 내에서: + +1. Settings > Notifications > Add Integration > Datadog 아이콘으로 이동합니다. + + ![Datadog 통합 추가][1] + +2. 별명과 Datadog 계정의 API 키를 입력합니다. 통합을 활성화하고 테스트합니다. + + ![Datadog API 키 설정][2] + +3. 테스트 작동을 확인하면 저장을 클릭합니다. + + ![활성된 Datadog 통합 저장][3] + +4. Settings > Notifications에서 Datadog에 보내고 싶은 [알림을 선택][4]합니다. + + ![Datadog 알림 활성화][5] + +## 수집한 데이터 + +이 통합은 이벤트를 Datadog로 전송합니다. + +## 지원 + +이 통합과 관련해 도움이 필요할 경우 [Datadog 지원팀][6]에 문의하시기 바랍니다. + + +[1]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/sedai/images/DataDog_Notification_Integration.png +[2]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/sedai/images/Add_DataDog_Channel.png +[3]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/sedai/images/Add_DataDog_Channel-Working_REC.png +[4]: https://sedai.gitbook.io/sedai/sedai-user-guide/controls/notifications +[5]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/sedai/images/Enable_Notifications.png +[6]: https://docs.datadoghq.com/ko/help/ \ No newline at end of file From bed06132904aca5be39f0504bfed3c89c69905ea Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 12:16:24 +0100 Subject: [PATCH 15/29] Translated file updates --- content/ko/dynamic_instrumentation/_index.md | 150 ++++++++++--------- 1 file changed, 78 insertions(+), 72 deletions(-) diff --git a/content/ko/dynamic_instrumentation/_index.md b/content/ko/dynamic_instrumentation/_index.md index 0927154f9be26..1ee6c0dc981ab 100644 --- a/content/ko/dynamic_instrumentation/_index.md +++ b/content/ko/dynamic_instrumentation/_index.md @@ -29,127 +29,133 @@ private: false title: 동적 계측 --- +{{% site-region region="gov" %}} +
+ 동적 계측은 선택한Datadog ({{< region-param key="dd_site_name" >}}) 사이트를 지원하지 않습니다. 이 기능을 사용하려면 원격 설정을 활성화해야 합니다. +
+{{% /site-region %}} + ## 개요 -동적 계측을 사용하면 재시작 없이도 타사 라이브러리를 포함하여 애플리케이션 코드의 어느 위치에서든 실행 중인 프로덕션 시스템에 계측을 추가할 수 있습니다. 또한, Datadog UI에서 로그, 메트릭, 스팬 및 해당 태그 지정에 대한 원격 분석을 추가하거나 수정할 수 있습니다. 동적 계측은 오버헤드가 낮고 시스템에 부작용이 없습니다. +동적 계측을 사용하면 서드 파티 라이브러리를 포함하여, 애플리케이션 코드의 어느 부분에서든 재시작 없이 실행 중인 프로덕션 시스템에 계측 기능을 추가할 수 있습니다. Datadog UI에서 로그, 메트릭, 스팬, 해당 태그에 대한 텔레메트리를 추가하거나 수정할 수 있습니다. 동적 계측은 오버헤드가 낮고 시스템에 부작용을 일으키지 않습니다. -Dynamic Instrumentation에 대한 최신 개선 사항을 시험해 보고 싶다면 [자동 완성 및 검색 Preview][17]를 선택하는 것이 좋습니다. +동적 계측의 최신 사용자 경험 개선 사항을 사용해 보고 싶다면, [자동완성 및 검색 미리보기][17]를 활성화해 보세요. ## 시작하기 -### 사전 필수 조건 +### 필수 요건 -동적 계측에는 다음이 필요합니다. +동적 계측 기능을 사용하려면 다음이 조건을 충족해야 합니다. -- [Datadog Agent][1] 7.45.0 이상이 서비스와 함께 설치됩니다. -- 해당 Agent에 [원격 설정][2]이 활성화되어 있습니다. -- Java 애플리케이션의 경우 추적 라이브러리 [`dd-trace-java`][3] 1.34.0 또는 이상. -- Python 애플리케이션의 경우 추적 라이브러리 [`dd-trace-py`][4] 2.2.0 이상. -- .NET 애플리케이션의 경우 추적 라이브러리 [`dd-trace-dotnet`][5] 2.54.0 또는 이상. -- (제한된 미리보기) Node.js 애플리케이션의 경우 추적 라이브러리 [`dd-trace-js`][18] 5.39.0 이상. -- (제한된 Preview) Ruby 애플리케이션의 경우 추적 라이브러리 [`dd-trace-rb`][19] 2.9.0 또는 이상. -- (제한된 미리보기) PHP 애플리케이션의 경우 추적 라이브러리 [`dd-trace-php`][20] 1.5.0 이상. -- [통합 서비스 태깅][6] 태그 `service`, `env` 및 `version`가 배포에 적용됩니다. -- (권장 사항) [자동 완성 및 검색(Preview 단계)][17]이 활성화됩니다. -- (권장 사항) [소스코드 통합][7]이 서비스에 설정되어 있습니다. -- Dynamic Instrumentation 페이지에 접근하려면 **Dynamic Instrumentation Read Configuration**(`debugger_read`) 권한이 필요합니다. -- 계측을 생성하거나 수정하려면 **Dynamic Instrumentation Write Configuration**(`debugger_write`) 권한이 필요합니다. -- **Capture method parameters and local variables** 옵션을 사용하려면**Dynamic Instrumentation Capture Variables**(`debugger_capture_variables`) 권한이 필요합니다. +- [Datadog Agent][1] 7.45.0 이상이 서비스와 함께 설치되어 있습니다. +- Agent에 [원격 설정][2]이 활성화되어 있습니다. +- Java 애플리케이션의 경우, 추적 라이브러리 버전이 [`dd-trace-java`][3] 1.34.0 이상입니다. +- Python 애플리케이션의 경우, 추적 라이브러리 버전이 [`dd-trace-py`][4] 2.2.0 이상입니다. +- For .NET 애플리케이션의 경우, 추적 라이브러리 버전이 [`dd-trace-dotnet`][5] 2.54.0 이상입니다. +- (제한된 미리보기) Node.js 애플리케이션의 경우, 추적 라이브러리 버전이 [`dd-trace-js`][18] 5.39.0 이상입니다. +- (제한된 미리보기) Ruby 애플리케이션의 경우, 추적 라이브러리 버전이 [`dd-trace-rb`][19] 2.9.0 이상입니다. +- (제한된 미리보기) PHP 애플리케이션의 경우, 추적 라이브러리 버전이 [`dd-trace-php`][20] 1.5.0 이상입니다. +- [통합 서비스 태깅][6] 태그 `service`, `env`, `version`이 배포 환경에 적용되어 있습니다. +- 권장: [자동완성 및 검색(미리보기)][17]이 활성화되어 있습니다. +- 권장: [소스 코드 통합][7]이 설정되어 있습니다. +- **동적 계측 읽기 설정** (`debugger_read`) 권한이 동적 계측 페이지 접근에 필요합니다. +- **동적 계측 쓰기 설정** (`debugger_write`) 권한이 계측을 생성 및 수정하는 데 필요합니다. +- **메서드 매개변수 및 로컬 변수 캡처**를 사용하려면 **동적 계측 캡처 변수** (`debugger_capture_variables`) 권한이 필요합니다. - 역할 및 사용자에게 역할을 할당하는 방법에 대한 자세한 내용은 [역할 기반 접근 제어][8]를 참조하세요. + 역할 및 사용자에게 역할을 할당하는 방법에 대한 자세한 내용을 확인하려면 [역할 기반 액세스 제어l][8]를 참조하세요. -### 로그 인덱스 만들기 +### 로그 인덱스 생성 -동적 계측은 Datadog으로 전송되고 일반 애플리케이션 로그와 함께 표시되는 "동적 로그"를 생성합니다. +동적 계측은 Datadog에 전송되고 일반 애플리케이션 로그와 같이 표시되는 '동적 로그'를 생성합니다. -[제외 필터][9]를 사용하는 경우 동적 계측 로그가 필터링되지 않는지 확인하세요. +[제외 필터][9]를 사용하는 경우, 다음과 같이 동적 계측 로그가 필터링되지 않도록 주의합니다. -1. 로그 인덱스를 생성하고 **no sampling**을 사용하여 원하는 보존으로 [설정][10]합니다. -2. `source:dd_debugger` 태그와 일치하도록 필터를 설정합니다. 모든 동적 계측 로그에는 이 소스가 있습니다. -3. 첫 번째 일치 항목이 적합하므로 새 색인이 해당 태그와 일치하는 필터가 있는 다른 색인보다 우선하도록 하세요. +1. 로그 인덱스를 생성하고 **샘플링 없이** 원하는 보존 기간을 [설정][10]합니다. +2. `source:dd_debugger` 태그와 매칭되도록 필터를 설정합니다. 모든 동적 계측 로그에는 이 소스가 있습니다. +3. 새 인덱스가 해당 태그와 매칭되는 필터가 있는 다른 인덱스보다 우선하도록 설정합니다. 먼저 매칭되는 인덱스가 우선하여 적용되기 때문입니다. ### 동적 계측 활성화 -서비스에서 동적 계측을 활성화하려면 [인앱 설정 페이지][16]로 이동하세요. +서비스에서 동적 계측을 활성화하려면 [인앱 설정 페이지][16]로 이동합니다. -자세한 지침을 보려면 아래에서 런타임을 선택하세요. +자세한 지침을 확인하려면 다음 런타임을 선택하세요. {{< partial name="dynamic_instrumentation/dynamic-instrumentation-languages.html" >}} -### 한계 +### 제한 -- 동적 계측은 아직 Azure App Services 또는 서버리스 환경과 호환되지 않습니다. -- Python, Java, .NET으로 구축된 애플리케이션에 대해서만 지원이 제공됩니다. -- Node.js, Ruby, PHP로 구축된 애플리케이션에 대한 제한된 미리보기가 진행 중입니다. +- 동적 계측은 아직 Azure App Service 또는 서버리스 환경과 호환되지 않습니다. +- Python, Java, .NET.로 빌드한 애플리케이션만 전체 지원이 제공됩니다. +- Node.js, Ruby, PHP로 빌드한 애플리케이션용으로 제한된 미리보기가 진행 중입니다. -## 동적 계측 살펴보기 +## 동적 계측 탐색 -동적 계측은 애플리케이션이 런타임에 수행하는 작업을 이해하는 데 도움이 됩니다. 동적 계측 프로브를 추가하면 코드를 변경하거나 다시 배포할 필요 없이 애플리케이션에서 추가 데이터를 내보낼 수 있습니다. +동적 계측은 애플리케이션의 런타임 동작을 이해할 수 있도록 도와드립니다. 동적 계측 프로브를 추가하면 코드를 변경하거나 재배포하지 않고도 애플리케이션에서 추가 데이터를 내보낼 수 있습니다. -### 프로브 사용하기 +### 프로브 사용 -프로브를 사용하면 프로그램 실행을 중단하지 않고도 코드의 특정 지점에서 데이터를 수집할 수 있습니다. +프로브로 프로그램 실행을 중단하지 않고 코드의 특정 지점에서 데이터를 수집할 수 있습니다. -프로브를 사용하면 코드를 변경하고 배포하거나 서비스를 다시 시작하지 않고도 실행 중인 애플리케이션에 동적 로그, 메트릭 및 스팬을 추가하여 옵저버빌리티를 향상시킬 수 있습니다. 사용자 경험을 방해하거나 장시간 배포 없이 즉시 데이터를 수집할 수 있습니다. +코드를 변경하거나 배포 또는 서비스를 재시작하지 않고도 실행 중인 애플리케이션에 동적 로그, 메트릭, 스팬을 추가하여 관측성을 향상시킬 수 있는 방안으로 프로브를 고려해 보시기 바랍니다. 사용자 환경을 방해하거나 장시간 배포하지 않고도 바로 데이터를 수집할 수 있습니다. -개발자로서는 프로브를 "중단되지 않는 중단점"이라고 생각할 수도 있습니다. 전통적인 디버깅에서는 중단점이란 프로그램 실행을 중지하는 지점으로, 개발자는 그 시점에서 프로그램의 상태를 검사할 수 있습니다. 그러나 실제 프로덕션 환경에서 프로그램 실행을 중지하는 것은 현실적이지 않으며 불가능합니다. 프로브는 방해가 되지 않는 방식으로 프로덕션 환경의 변수 상태를 검사할 수 있도록 하여 이러한 격차를 해소합니다. +개발자는 프로브를 '비중단 중단점(Non-breaking breakpoint)'이라고 생각하면 좋습니다. 기존 디버깅에서 중단점은 프로그램 실행이 중단되는 지점으로, 개발자가 해당 지점의 프로그램 상태를 조사할 수 있게 합니다. 그러나 실제 운영 환경에서는 프로그램 실행을 중단하는 것이 현실적이지 않거나 아예 가능하지 않습니다. 프로브는 이러한 프로덕트 운영 환경에서 비침입적 방식으로 변수 상태를 검사할 수 있도록 도와줌으로써 이러한 한계를 보완합니다. -### 프로브 만들기 +### 프로브 생성 -모든 프로브 유형에는 동일한 초기 설정이 필요합니다. +모든 프로브 유형은 다음과 같은 초기 설정이 필요합니다. -1. [Dynamic Instrumentation 페이지][12]로 이동합니다. -1. 오른쪽 상단에서 **Create Probe**를 클릭하거나 서비스에서 점 3개 메뉴를 클릭하고 **Add a probe for this service**를 선택합니다. -1. 미리 채워져 있지 않은 경우 서비스, 런타임, 환경 및 버전을 선택합니다. -1. 소스 코드에서 클래스와 메서드 또는 소스 파일과 줄을 선택하여 프로브를 설정할 위치를 지정합니다. [자동 완성 및 검색 Preview][17]를 선택하면 자동 완성 기능은 클래스나 메서드 선택에 대한 제안 사항을 표시합니다. +1. [동적 계측 페이지][12]로 이동합니다. +1. 오른쪽 상단의 **Create Probe**를 클릭하거나 서비스 메뉴에서 점 세 개를 클릭하고 **Add a probe for this service**를 선택합니다. +1. 정보가 미리 채워지지 않은 경우 서비스, 런타임, 환경, 버전을 선택합니다. +1. 소스 코드에서 클래스와 메서드 또는 소스 파일 및 라인 중 하나를 선택하여 프로브를 설정할 위치를 지정합니다. [자동완성 및 검색 미리보기][17]를 설정한 경우, 자동 완성 기능은 클래스 또는 메서드 선택 제안을 제시합니다. -각 프로브 유형에 대한 특정 생성 단계는 아래의 개별 프로브 유형을 참조하세요. +각 프로브 유형에 대한 개별 생성 단계는 다음 개별 프로브 유형을 참조하세요. -또는 다음과 같은 다른 컨텍스트에서 프로브를 생성할 수 있습니다. +또는 다음과 같은 컨텍스트에서 프로브를 생성합니다. 프로파일링 -: 프로파일러 플레임 그래프에서 프레임의 컨텍스트 메뉴에 있는 **Instrument this frame with a probe**를 선택하여 메서드에 대한 프로브를 생성할 수 있습니다. +: 프로파일러 플레임 그래프에서 프레임 컨텍스트 메뉴의 **Instrument this frame with a probe**를 선택하여 메서드용 프로브를 생성합니다. 오류 추적 -: 스택 추적에서 스택 프레임 위에 마우스를 놓고 **Instrument**를 클릭합니다. 이렇게 하면 Issue context로 프로브 생성 양식이 미리 채워집니다. +: 스택 트레이스(stack trace)에서 스택 프레임에 마우스를 올리고 **Instrument**를 클릭합니다. 그러면 프로브 생성 양식에 오류 컨텍스트가 미리 채워집니다. -### 로그 프로브 만들기 +### 로그 프로브 생성 -*로그 프로브*는 실행될 때 로그를 내보냅니다. +A *로그 프로브*는 실행 시 로그를 출력합니다. -로그 프로브를 생성하려면: +다음에 따라 로그 프로브를 생성합니다. -1. 프로브 유형으로 **Log**를 선택합니다. -1. [일반 프로브 설정](#creating-a-probe)을 완료합니다(서비스, 환경, 버전 및 프로브 위치 선택). -1. 로그 메시지 템플릿을 정의합니다. 동적 계측 표현 언어를 사용하여 실행 컨텍스트의 값을 참조할 수 있습니다. -1. 필요한 경우 프로브에서 추가 데이터 캡처를 활성화합니다. (베타) -1. 필요한 경우 동적 계측 표현 언어를 사용하여 조건을 정의합니다. 표현식이 true로 평가되면 로그가 내보내집니다. +1. 프로브 유형으로 **로그**를 선택합니다. +1. [일반 프로브 설정](#creating-a-probe)(서버, 환경, 버전, 프로브 위치 선택)을 완료합니다. +1. 로그 메시지 템플릿을 정의합니다. 동적 계측 정규 표현식으로 실행 컨텍스트 값을 참조할 수 있습니다. +1. 옵션으로 프로브에서 추가 데이터 캡처 기능을 활성화합니다(베타 버전). +1. 옵션으로 동적 계측 정규 표현식으로 조건을 정의합니다. 표현식이 True로 산출되면 로그가 출력됩니다. -로그 프로브는 지정된 환경 및 버전과 일치하는 모든 서비스 인스턴스에서 기본적으로 활성화됩니다. 서비스의 각 인스턴스에서 초당 최대 5000회가 실행되도록 속도가 제한되어 있습니다. +로그 프로브는 지정한 환경 또는 버전과 일치하는 모든 서비스 인스턴스에서 기본값으로 활성화됩니다. 서비스의 각 인스턴스에서 초당 최대 5,000회 실행되는 속도 제한이 있습니다. -모든 로그 프로브에 로그 메시지 템플릿을 설정해야 합니다. 템플릿은 중괄호 안에 [표현식][15]을 포함하는 것을 지원합니다 (예: `User {user.id} purchased {count(products)} products`). +모든 로그 프로브에 로그 메시지 템플릿을 반드시 지정해야 합니다. 해당 템플릿은 중괄호 안에 [정규 표현식][15]을 삽입할 수 있도록 지원합니다. 예시: `User {user.id} purchased {count(products)} products`. -[표현 언어][15]를 사용하여 로그 프로브에 대한 조건을 설정할 수도 있습니다. 표현식은 부울로 평가되어야 합니다. 식이 true이면 프로브가 실행되고, 식이 false이면 데이터를 캡처하거나 내보내지 않습니다. +[정규 표현식][15]으로 로그 프로브에 조건을 설정할 수도 있습니다. 정규 표현식은 반드시 부울로 결과값이 산출되어야 합니다. 표현식이 True면 프로브가 실행되고, False면 데이터를 캡처 또는 출력하지 않습니다. -{{< img src="dynamic_instrumentation/log_probe.png" alt="동적 계측 로그 프로브 만들기" >}} +{{< img src="dynamic_instrumentation/log_probe.png" alt="동적 계측 로그 프로브 생성하기" >}} -**베타**: 로그 프로브에서 **Capture method parameters and local variables**를 활성화하면 모든 실행 컨텍스트가 로그 이벤트에 추가됩니다. - - **메서드 인수**, **로컬 변수** 및 **필드**(다음과 같은 기본 제한 포함): - - 3단계 깊이의 참조를 따릅니다 (UI에서 설정 가능). - - 컬렉션의 처음 100개 항목. - - 문자열 값의 처음 255자. - - 개체 내부의 20개 필드. 정적 필드는 수집되지 않습니다. - - **스택 트레이스**를 호출합니다. - - 캡처되거나 캡처되지 않은 **예외**. +**베타**: 로그 프로브에서 **메서드 파라미터 및 로컬 변수 캡처**를 활성화하면 다음의 모든 실행 컨텍스트가 로그 이벤트에 추가됩니다. + - 다음 기본 제한이 적용된 **메서드 인수**, **로컬 변수**, **필드**: + - 세 단계 깊이의 참조를 따름(UI에서 설정 가능). + - 컬렉션 내 첫 100개 아이템. + - 문자열 값의 경우 첫 255자. + - 오브젝트 내 20개 필드. 정적 필드는 수집되지 않습니다. + - **스택 트레이스(stack trace)**를 호출합니다. + - 처리되거나 처리되지 않은 **예외**. -이 설정이 활성화된 프로브는 초당 1회 적중으로 속도가 제한됩니다. +해당 설정이 적용된 프로브는 초당 한 번만 실행되는 속도 제한이 있습니다. -

경고: 캡처된 데이터에는 개인 데이터, 비밀번호, AWS 키 등 민감한 정보가 포함될 수 있습니다.

이러한 정보가 적절하게 삭제되었는지 확인하세요.

    -
  • Datadog 동적 계측은 민감한 정보를 삭제하기 위해 여러 가지 기술을 사용합니다. 기본 메커니즘 또는 필요에 맞게 확장하는 방법에 대해 자세히 알아보려면 민감한 데이터 스크러빙을 참조하세요.
    • -
  • 캡처 방법 파라미터 및 로컬 변수 옵션을 끄고 로그 메시지 템플릿에 포함할 변수를 명시적으로 선택합니다. 이렇게 하면 로그 프로브에 구체적으로 식별한 변수와 관련된 데이터만 포함되므로 의도하지 않은 민감한 데이터 유출의 위험을 줄일 수 있습니다.
    • -
  • Datadog 계정의 관리자로서 다른 사용자가 캡처 방법 파라미터 및 로컬 변수 옵션을 사용하지 못하도록 하려면 동적 계측 변수 캡처(debugger_capture_variables) 권한을 취소할 수 있습니다.

또는 로그을 남겨야 하지만 Datadog 제품에서 이 데이터에 액세스할 수 있는 위험을 완화하려는 경우 source:dd_debugger에 제한 쿼리 을 설정하여 조직에서 캡처된 데이터를 볼 수 있는 사용자를 제한할 수 있습니다.

+

경고: 캡처된 데이터는 개인정보, 비밀번호 AWS 키와 같은 시크릿 등의 민감한 정보를 포함할 수도 있습니다.

다음에 따라 해당 정보를 적절히 마스킹합니다.

    +
  • Datadog Dynamic Instrumentation은 여러 가지 기술을 활용하여 민감한 정보를 마스킹합니다. 기본 메커니즘에 대해 자세히 알아보거나 이를 요구 사항에 맞게 확장하는 방법을 확인하려면 민감 정보 스크러빙 항목을 참조하세요.
    • +
  • 메서드 파라미터 및 로컬 변수 캡처 옵션을 비활성화하고 로그 메시지 템플릿에 포함하려는 변수를 명시적으로 선택합니다. 이렇게 하면 로그 프로브에는 사용자가 구체적으로 지정한 변수와 관련된 데이터만 포함되므로 의도치 않게 민감한 데이터가 유출되는 위험을 줄일 수 있습니다.
    • +
  • Datadog 계정 관리자로서 다른 사용자가 메서드 파라미터 및 로컬 변수 캡처 옵션을 사용하지 못하게 설정하려면, 해당 사용자의 동적 계측 캡처 변수(debugger_capture_variables) 권한을 취소합니다.

또는, 이 데이터를 로깅해야 하지만 Datadog 제품으로 접근하는 것을 방지하려면 source:dd_debugger에 제한 쿼리를 설정하여 조직 내에서 캡처된 데이터를 확인할 수 있는 사용자를 제한할 수 있습니다

.
### 메트릭 프로브 생성하기 From 974023ec08ecd3e3da341402bd2e63bd41e67231 Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:55:13 +0100 Subject: [PATCH 16/29] Deleting translations of content/ja/partners/billing-and-usage-reporting.md --- .../partners/billing-and-usage-reporting.md | 29 ------------------- 1 file changed, 29 deletions(-) delete mode 100644 content/ja/partners/billing-and-usage-reporting.md diff --git a/content/ja/partners/billing-and-usage-reporting.md b/content/ja/partners/billing-and-usage-reporting.md deleted file mode 100644 index 357e1347eb6e7..0000000000000 --- a/content/ja/partners/billing-and-usage-reporting.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -description: 複数組織のアカウント設定における、Datadog プラットフォームの個々のクライアントおよび集計使用量の監視。 -private: true -title: 請求と使用量報告 ---- - -複数組織のアカウントで、Datadog プラットフォームの個々のクライアントと集計された使用量の両方を監視する方法については、こちらをご覧ください。 - -親組織に Datadog の[管理者ロール][1]があれば、子組織と親組織のすべての組織の合計と請求可能な使用量、および顧客の使用量が過去 6 ヶ月間でどう変化したかを確認することができます。詳しくは、[複数組織の使用量][2]をご覧ください。 - -使用量は、すべての子組織に集計され、親組織レベルで請求されます。親組織の管理者ロールを持つ人は、すべての子組織の使用量を集計したり、個々の子組織の使用量をさらに分析したりすることができます。 - -既存のロールがあなたやクライアント組織にとって十分に柔軟でない場合、新しいカスタムロールを作成することができます。カスタムロールを使用すると、一般的な権限に加えて、特定のアセットやデータ型に対してより詳細な権限を定義することが可能になります。請求量と使用量のアセットに固有の権限の一覧は、[ロールベースアクセスコントロールのドキュメント][3]に記載されています。 - -使用量のページに加え、クライアントの使用量を見積もり、管理し、簡単な配分とチャージバックを提供するために使用できる追加リソースをご紹介します。 -- [推定使用量メトリクス][4]: Datadog は、クライアントの現在の推定使用量をほぼリアルタイムで計算します。推定使用量メトリクスにより、推定使用量のグラフ化、選択したしきい値に基づく推定使用量に関するモニターやアラートの作成、使用量の急増や減少に関する即時アラートの取得が可能になります。 -- [共有ダッシュボード][5]: 共有ダッシュボードとグラフを使用すると、Datadog の外部のユーザーとメトリクス、トレース、ログの視覚化を表示することができます。使用量推定メトリクスダッシュボードを公開し、クライアントが追跡できるようにすることができます。 -- [使用属性][6]: - - 使用方法が分類されている既存のタグキーのリストを提供し、新しいタグを変更・追加する機能を提供します。 - - ほとんどの使用タイプの日次 .tsv ファイル（タブ区切り値）を生成します。 - - 子組織だけでなく、タグごとの使用量を月末に集計します。 - 使用属性は、Enterprise プランに含まれる高度な機能であることに注意してください。その他のプランについては、Datadog パートナー担当者にお問い合わせの上、この機能をリクエストしてください。 - -[1]: /ja/account_management/rbac/ -[2]: /ja/account_management/multi_organization/#multi-org-usage -[3]: /ja/account_management/rbac/permissions/?tab=ui#billing-and-usage -[4]: /ja/account_management/billing/usage_metrics/ -[5]: /ja/dashboards/sharing/ -[6]: /ja/account_management/billing/usage_attribution/ \ No newline at end of file From a1bff5fc059c5fb97bc93c4a391215a9f56b6fd4 Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:55:27 +0100 Subject: [PATCH 17/29] Deleting translations of content/fr/partners/billing-and-usage-reporting.md --- .../partners/billing-and-usage-reporting.md | 30 ------------------- 1 file changed, 30 deletions(-) delete mode 100644 content/fr/partners/billing-and-usage-reporting.md diff --git a/content/fr/partners/billing-and-usage-reporting.md b/content/fr/partners/billing-and-usage-reporting.md deleted file mode 100644 index 6ae83bc190640..0000000000000 --- a/content/fr/partners/billing-and-usage-reporting.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -description: Surveillez l'utilisation de la plateforme Datadog par vos différents - clients et l'utilisation globale avec un compte multi-organisations. -private: true -title: Données d'utilisation et de facturation ---- - -Lisez cet article pour découvrir comment surveiller l'utilisation de la plateforme Datadog par vos différents clients et l'utilisation globale avec votre compte multi-organisations. - -Si vous disposez du [rôle admin][1] Datadog dans l'organisation parent, vous pouvez consulter l'utilisation totale et l'utilisation facturée de toutes vos organisations (parent et enfant) ainsi que l'évolution de l'utilisation de vos clients au cours des six derniers mois. Pour en savoir plus, consultez la section [Utilisation pour plusieurs organisations][2]. - -L'utilisation est calculée pour l'ensemble des organisations enfant et facturée au niveau de l'organisation parent. Depuis l'organisation parent, les utilisateurs disposant du rôle admin peuvent consulter l'utilisation globale de toutes les organisations enfant et analyser l'utilisation d'une organisation enfant spécifique. - -Si les rôles existants ne sont pas assez flexibles pour vous ou votre organisation client, vous pouvez créer de nouveaux rôles personnalisés. Lorsqu'ils sont combinés aux autorisations générales, les rôles personnalisés permettent de définir des autorisations plus granulaires pour des ressources ou des types de données spécifiques. La liste des autorisations spécifiques aux ressources de facturation et d'utilisation est disponible dans la section [Contrôle d'accès à base de rôles (RBAC)][3]. - -En plus des données d'utilisation, voici quelques ressources supplémentaires que vous pouvez utiliser pour estimer et gérer l'utilisation de vos clients, mais aussi pour simplifier l'attribution des ressources et la rétrofacturation : -- [Métriques d'estimation de l'utilisation][4] : Datadog calcule l'utilisation estimée actuelle de vos clients en temps quasi-réel. Les métriques d'estimation de l'utilisation vous permettent de créer des graphiques représentant l'utilisation estimée, de créer des monitors ou des alertes en fonction des seuils d'utilisation de votre choix, et d'être instantanément prévenu en cas de hausse ou de baisse soudaine de votre utilisation. -- [Dashboards partagés][5] : les dashboards et les graphiques partagés vous permettent d'afficher des visualisations de métrique, de trace et de log en dehors de Datadog. Publiez des dashboards représentant les métriques d'estimation de l'utilisation pour que vos clients puissent suivre ces données. -- [Attribution de l'utilisation][6] : - - Énumère les différentes clés de tag utilisées pour répartir l'utilisation et permet d'ajouter ou de modifier de nouvelles clés. - - Génère des fichiers .tsv (valeurs séparées par des tabulations) quotidiens pour la plupart des types d'utilisation. - - Affiche un résumé de l'utilisation à la fin de chaque mois pour chaque organisation enfant et pour chaque tag. - Notez que l'attribution de l'utilisation est une fonction avancée incluse dans la formule Enterprise. Si vous utilisez une autre formule, contactez votre chargé de compte pour demander l'activation de cette fonctionnalité. - -[1]: /fr/account_management/rbac/ -[2]: /fr/account_management/multi_organization/#multi-org-usage -[3]: /fr/account_management/rbac/permissions/?tab=ui#billing-and-usage -[4]: /fr/account_management/billing/usage_metrics/ -[5]: /fr/dashboards/sharing/ -[6]: /fr/account_management/billing/usage_attribution/ \ No newline at end of file From 0e258f36bc2341e7650555cbba4c10e3d227999f Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:55:40 +0100 Subject: [PATCH 18/29] Deleting translations of content/es/partners/billing-and-usage-reporting.md --- .../partners/billing-and-usage-reporting.md | 30 ------------------- 1 file changed, 30 deletions(-) delete mode 100644 content/es/partners/billing-and-usage-reporting.md diff --git a/content/es/partners/billing-and-usage-reporting.md b/content/es/partners/billing-and-usage-reporting.md deleted file mode 100644 index 459782820e0c1..0000000000000 --- a/content/es/partners/billing-and-usage-reporting.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -description: Monitorización del uso de cliente individual y el uso agregado de la - plataforma de Datadog en configuraciones de cuenta de varias organizaciones. -private: true -title: Facturación e informes de uso ---- - -Sigue leyendo para obtener información sobre cómo monitorizar tanto el uso del cliente individual como el uso agregado de la plataforma de Datadog en tu cuenta de múltiples organizaciones. - -Con un [rol de administrador][1] de Datadog en la organización principal, puedes ver el uso total y facturable de todas tus organizaciones, secundarias y principal, así como cómo ha cambiado el uso de tus clientes en los últimos seis meses. Para obtener más información, consulta [Uso de varias organizaciones][2]. - -El uso se agrega por todas las organizaciones secundarias y se factura a nivel de la organización principal. Desde la organización principal, los administradores pueden ver el uso agregado de todas las organizaciones secundarias y analizar el uso de cada una de ellas. - -En caso de que los roles existentes no sean lo suficientemente flexibles para ti o tu organización de cliente, puedes crear nuevos roles personalizados. Con los roles personalizados, además de los permisos generales, es posible definir permisos más detallados para activos o tipos de datos específicos. Puedes encontrar la lista de permisos específicos para la facturación y activos de uso [en la documentación del Control de acceso basado en roles][3]. - -Además de la página de uso, aquí tienes algunos recursos adicionales que puedes utilizar para estimar y gestionar el uso de los clientes, así como para facilitar las asignaciones y las devoluciones de cargos: -- [Métricas de uso estimado][4]: Datadog calcula el uso estimado actual de tus clientes casi en tiempo real. Las métricas de uso estimado te permiten hacer gráficos de tu uso estimado, crear monitores o alertas en torno a tu uso estimado en función de los umbrales que elijas y recibir alertas instantáneas sobre picos o caídas en tu uso. -- [Dashboards compartidos][5]: los gráficos y dashboards compartidos te permiten mostrar visualizaciones de métricas, trazas y logs a tus usuarios fuera de Datadog. Puedes publicar dashboards de métricas de uso estimado para que tus clientes realicen un seguimiento. -- [Atribución de uso][6]: - - Proporciona listas a las claves de etiqueta existentes por las que se está desglosando el uso y ofrece la posibilidad de cambiar y añadir nuevas etiquetas. - - Genera diariamente archivos .tsv (valores separados por tabulaciones) para la mayoría de los tipos de uso. - - Resume el uso al final de cada mes, no sólo por organizaciones secundarias, sino también por etiqueta. - Ten en cuenta que la atribución de uso es una función avanzada incluida en el plan Enterprise. Para el resto de los planes, ponte en contacto con tu representante de socios de Datadog para solicitar esta función. - -[1]: /es/account_management/rbac/ -[2]: /es/account_management/multi_organization/#multi-org-usage -[3]: /es/account_management/rbac/permissions/?tab=ui#billing-and-usage -[4]: /es/account_management/billing/usage_metrics/ -[5]: /es/dashboards/sharing/ -[6]: /es/account_management/billing/usage_attribution/ \ No newline at end of file From 9694add336c95de978eea648a5f0466b804ce70c Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:55:54 +0100 Subject: [PATCH 19/29] Deleting translations of content/ko/partners/billing-and-usage-reporting.md --- .../partners/billing-and-usage-reporting.md | 29 ------------------- 1 file changed, 29 deletions(-) delete mode 100644 content/ko/partners/billing-and-usage-reporting.md diff --git a/content/ko/partners/billing-and-usage-reporting.md b/content/ko/partners/billing-and-usage-reporting.md deleted file mode 100644 index f26d4f291f80d..0000000000000 --- a/content/ko/partners/billing-and-usage-reporting.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -description: 여러 조직 계정 설정에서 개별 클라이언트 및 Datadog 플랫폼 사용량 합계를 모니터링하기 -private: true -title: 빌링 및 사용량 보고 ---- - -여러 조직 계정에서 Datadog 플랫폼 사용량 합계 및 개별 클라이언트를 모니터링하는 방법을 알아봅니다. - -상위 조직의 Datadog [관리자 역할][1]로 상위 및 하위 조직 전체의 총 청구 사용량과 최근 6개월 간 사용량 변화 추이를 확인할 수 있습니다. 자세한 정보는 [여러 조직 사용량][2]을 참고하세요. - -하위 조직 전체의 사용량 총계가 상위 조직 수준에서 청구됩니다. 상위 조직에서 관리자 역할이 있는 사용자는 하위 조직의 총 사용량을 볼 수 있고 각 하위 조직별 사용량을 세부적으로 분석할 수 있습니다. - -클라이언트 조직이나 내가 사용 중인 기존 역할이 유연하지 않은 경우, 새 커스텀 역할을 만들 수 있습니다. 일반 권한과 더불어 커스텀 역할을 이용해 특정 에셋이나 데이터 유형에 맞게 세부적으로 권한을 정의할 수 있습니다. 빌링 및 사용량 에셋과 관련한 권한 목록을 보려면 [역할 기반 액세스 컨트롤 설명서][3]를 참고하세요. - -사용량 페이지에 더해 클라이언트 사용량을 예측 및 관리하고 사용량 분배와 차지백을 용이하게 하는 방법에 관한 추가 리소스도 있습니다. -- [Estimeated Usage Metrics][4]: Datdog에서는 클라이언트의 현재 예측 사용량을 실시간에 가깝게 계산할 수 있습니다. 예측 사용량 메트릭을 이용해 예측 사용량을 그래프화하고, 선택한 제한 값을 기반으로 예측 사용량의 모니터링 및 알림을 생성하고, 사용량이 급증하거나 급감할 때 즉시 알림을 받을 수 있습니다. -- [Shared Dashboards][5]: 공유된 대시보드와 그래프를 사용하면 Datadog 외 사용자에게 메트릭, 트레이스, 로그를 가시화하여 보여줄 수 있습니다. 클라이언트가 추적할 수 있도록 예측 사용량 메트릭 대시보드를 게시할 수 있습니다. -- [Usage Attribution][6]: - - 사용량이 분석된 기존 태그 키 목록과 새 태그를 추가 및 변경할 수 있는 기능 제공. - - 대부분의 사용량 유형에 일일 .tsv 파일(값으로 구분된 탭)을 생성. - - 매월 말 사용량 요약, 하위 조직별뿐만 아니라 태그별로 제공 - 사용량 속성은 엔터프라이즈 플랜에 포함된 고급 기능입니다. 다른 플랜을 사용 중인 경우, Datadog 파트너 담당자에게 연락해 이 기능을 요청하세요. - -[1]: /ko/account_management/rbac/ -[2]: /ko/account_management/multi_organization/#multi-org-usage -[3]: /ko/account_management/rbac/permissions/?tab=ui#billing-and-usage -[4]: /ko/account_management/billing/usage_metrics/ -[5]: /ko/dashboards/sharing/ -[6]: /ko/account_management/billing/usage_attribution/ \ No newline at end of file From 58830636049c5760ebe78b1578c9a03c071045c2 Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:56:09 +0100 Subject: [PATCH 20/29] Deleting translations of content/ja/partners/delivering-value.md --- content/ja/partners/delivering-value.md | 195 ------------------------ 1 file changed, 195 deletions(-) delete mode 100644 content/ja/partners/delivering-value.md diff --git a/content/ja/partners/delivering-value.md b/content/ja/partners/delivering-value.md deleted file mode 100644 index caa1c485bd412..0000000000000 --- a/content/ja/partners/delivering-value.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -description: Datadog にデータを流した後の推奨ステップ。 -private: true -title: 価値の提供 ---- - -データの取り込みを設定した後、さらにいくつかのステップを踏むことで、クライアントにとっての価値を最大化することができます。ここでは、注目すべき主要な領域をいくつか紹介します。 - -## モニターとダウンタイムの設定 - -モニターとアラートは、検査や介入が必要な特定のシステムやサービスに人間の注意を向けさせます。アラートを生成するために、Datadog は以下を提供します。 -- モニター - アラート条件の定義 -- ダウンタイム - アラートを発生させたり抑制したりする時間帯 - -一般的なモニターの概念に慣れるために、以下の資料を参照してください。 -- [アラート設定][1] -- [モニター入門 - 重要事項をアラート][2] (ブログ) -- [モニタリング入門][3] (トレーニング) - -### モニターの移行 - -サービスプロバイダーは、しばしばクライアントを別のモニタリングまたは観測可能性プラットフォームから Datadog に移行する必要があります。このような場合、以前のソリューションのモニターを Datadog で複製することが論理的に思えるかもしれません。このアプローチでは、Datadog の最も有用な機能の多くが使用されないままになってしまうことがよくあります。特に、問題の検出と解決時間を改善したり、アラート疲労を軽減したりする機能は見逃せません。 - -移行プロジェクトを開始する前に、既存のアラートおよびしきい値の定義を確認し、以下の質問に回答してください。 -- メトリクスに時間的な変動がありますか？[異常モニター][4]の方が良いかもしれません。 -- メトリクスに負荷に応じた変動がありますか？メトリクスに負荷を示すメトリクスを組み合わせることで、[演算モニター][5]が最適なアプローチとなるかもしれません。例えば、あるサービスを利用するユーザーが多ければ、システムの負荷は高くなる可能性があります。 -- メトリクスの絶対値は、変化率よりも重要ではないですか？[変化モニター][6]や[予測モニター][7]が最適なアプローチかもしれません。 -- メトリクスの値そのものは、他のホストやエンティティの値と異なるかどうかよりも重要性が低いですか？例えば、クラスター内のあるノードが高いレイテンシーを経験しているのに、他のノードはそうでない場合などです。このようなシナリオでは、[外れ値モニター][8]が最適なアプローチとなります。 -- 複数のメトリクスを組み合わせたものだけが、アクションを起こせる状況を示しますか？[複合条件モニター][9]は、スクリプトを必要としない解決策を提供します。 - -### プログラムモニター管理 - -サービスプロバイダーとして、あなたやクライアントのためのモニターの管理は、次のいずれかの方法でプログラム的に達成するのが最善です。 -- [Datadog モニター API][10] -- Terraform - - [Terraform を使った Datadog のリソース管理方法][11] (ビデオ) - - [Terraform Datadog Provider を使って監視を自動化する][12] (HashiCorp Tutorial) - -大量のモニターを簡単に管理するために、[モニターにタグを付ける][13]ことを徹底してください。 - -### 推奨モニター - -クライアントが運用するテクノロジーで、自分があまり経験のないものに遭遇することがあります。Datadog は、新しいテクノロジーを迅速かつ自信を持って導入できるように、[推奨モニター][14]を提供しています。 - -モニターについて詳しくは、こちらをご覧ください。 -- [モニターの管理][15] -- [モニター][16] -- [タグ値を使用したダイナミックアラートの作成][17] (ビデオ) -- [モニター設定の変更が反映されない][18] - -### ダウンタイム - -モニターやアラートに関する一般的な問題として、アラームや通知の過多によりアラームに対する感覚が鈍るアラート疲労があります。アラート疲労に対処する 1 つの方法は、誤検出アラートの数を制限することです。これは、計画的なシステムのシャットダウン、メンテナンス、アップグレードウィンドウなどの管理された状況において特に適切です。 - -Datadog のダウンタイムは、計画的 (またはアドホック) なメンテナンス時にモニターをミュートする方法をあなたやクライアントに提供します。 - -ダウンタイムの管理、特にプログラムによる管理について詳しくは、こちらをご覧ください。 -- [ダウンタイム][19] -- [計画されたダウンタイムのために Datadog アラートをミュートする][20] (ブログ) -- [Datadog を Terraform で管理する][21] (ブログ) -- [ダウンタイム API][22] -- [ダウンタイムになったモニターからのアラートを防止する][23] - -### 通知 - -通知に関する一般的なガイドラインをいくつか紹介します。 -- 自由なアラート、慎重なページ -- 原因ではなく、症状に関するページ - -Datadog は、あなたやクライアントが重要なアラートをユーザーに通知できるよう、様々なチャンネルを提供しています。 - -- メール通知 -- 以下などのインテグレーション - - [Slack][24] - - [PagerDuty][25] - - [Flowdock][26] - - [ServiceNow][27] - - [Google Chat][28] - - [Microsoft Teams][29] - - [その他にも多数あります][19] - -また、汎用的な [Webhooks インテグレーション][30]を使用して、任意の REST API を呼び出すことができます。Webhooks インテグレーションを使用すると、ユーザーに通知するだけでなく、自動的な修復ワークフローをトリガーすることができます。 - -通知について詳しくは、こちらをご覧ください。 -- [通知][31] -- [Webhooks と Twilio で SMS アラートを送る][32] (ブログ) - -## ダッシュボードを使って視覚化を設定する - -視覚化は、複雑な技術スタックや、収集された大量のメトリクスやイベントをクライアントに明確に伝えるための素晴らしい方法です。ダッシュボードは、あなたやクライアントがモニターから通知された潜在的な問題を調査するための自然な出発点です。 - -### すぐに使えるダッシュボード - -Datadog は、Agent やクラウドインテグレーションをセットアップした瞬間に、新しく統合されたサービスやテクノロジーに対してすぐに使えるダッシュボードを自動的に有効にし、インサイトを即座に提供します。また、すぐに使えるダッシュボードの複製も可能で、カスタムダッシュボードの出発点として最適です。 - -### カスタムダッシュボードの構築 - -さまざまなペルソナに合わせたビジネス中心の視点を提供することで、さらなる価値を提供し、競合他社と差別化することができます。 - -ここでは、ダッシュボードを構築する際に考慮すべきダッシュボードのベストプラクティスを紹介します。 -- 多すぎるリソースメトリクスよりも、ワークメトリクスに注目します。この違いを理解するには、[モニタリング入門: 正しいデータの収集][33] (ブログ) を参照してください。 -- [イベントオーバーレイ][34]を活用し、メトリクスとイベントの関連付けを行います。 -- ダッシュボードには、どのようなデータが表示され、ダッシュボードが問題を示している場合にどうすればよいか、[フリーテキスト情報][35]で注釈を付けます。 - -ダッシュボードについて詳しくは、こちらをご覧ください。 -- [より良いダッシュボードの構築][36] (トレーニング) -- [Datadog ノートブック][37]機能を使って探索的にデータを集め、ダッシュボードを起草する -- [Datadog でデータセンターとネットワークを監視する][38] (ブログ) -- [関連するテンプレート変数を使う][39] (ブログ) -- [Datadog ダッシュボード API][40] -- [Terraform と Datadog で観測可能性をコードで構成する][41] (HashiCorp ウェビナー) - -### Datadog にアクセスできないユーザー向けの視覚化 - -ビジネスモデルによっては、クライアント自身が Datadog にアクセスする必要がない場合があります。しかし、クライアントに Datadog の視覚化を提供したい場合があります。Datadog の視覚化を提供するには、次のオプションがあります。 -- [ダッシュボードの共有][42]: 読み取り専用のダッシュボードへの公開 URL を共有することで、クライアントにステータスページを提供したり、個々のメールアドレスを使用してダッシュボードを非公開で共有することができます。 - - サービスプロバイダーとして、ビジネスはスケーラブルであることが必要です。[Datadog の API を使用した共有ダッシュボードの管理][40]は、最も効率的なアプローチです。 -- 埋め込み可能なグラフ: クライアントポータルで Datadog の情報を表示する場合、埋め込み可能なグラフが有効です。パラメーターを使用すると、ニーズに合わせてデータをフィルターすることができます。詳細については、以下を参照してください。 - - [埋め込み可能なグラフ API][43] - - [テンプレート変数による埋め込み可能なグラフ][44] - -### サービスレベル目標の設定 - -クライアントに対して、サービスの品質やレベルを透明性のある形で継続的に提示することは、良いことです。サービスレベル目標 (SLO) は、クライアントに代わってサービス品質を監視・視覚化し、またクライアントが社内でサービスレベルに基づくレポーティングを実施する際にも有効な手段です。 - -SLO を設定・管理する際には、以下の資料が参考になるかと思われます。 -- まずは、[サービスレベル目標入門: 効果的な SLO の確立][45] (ブログ) をご覧ください。 -- [SLO チェックリスト][46] -- [Datadog で SLO を管理するためのベストプラクティス][47] (ブログ) -- [Datadog ですべての SLO のステータスを追跡する][48] (ブログ) -- [Datadog SLO API][49] - -## Watchdog の使用 - -Watchdog は、アプリケーションやインフラストラクチャーの潜在的な問題を自動的に検出するアルゴリズム機能です。 - -Watchdog が新たな不正を検出したときに通知を受け取ることができる Watchdog モニターを、自社のスタッフやクライアントのために設定します。 - -詳しくは、[Watchdog][50] をご覧ください。 - -## 次のステップ - -複数組織のアカウント設定において、Datadog プラットフォームの個々のクライアントおよび集計使用量を監視する方法を、[請求と使用量報告][51]でご確認ください。 - -[1]: /ja/monitors -[2]: https://www.datadoghq.com/blog/monitoring-101-alerting/ -[3]: https://learn.datadoghq.com/courses/introduction-to-observability -[4]: /ja/monitors/types/anomaly/ -[5]: /ja/monitors/guide/monitor-arithmetic-and-sparse-metrics/ -[6]: /ja/monitors/types/metric/?tab=change -[7]: /ja/monitors/types/forecasts/?tab=linear -[8]: /ja/monitors/types/outlier/?tab=dbscan -[9]: /ja/monitors/types/composite/ -[10]: /ja/api/latest/monitors/ -[11]: https://www.youtube.com/watch?v=Ell_kU4gEGI -[12]: https://learn.hashicorp.com/tutorials/terraform/datadog-provider -[13]: https://www.datadoghq.com/blog/tagging-best-practices-monitors/ -[14]: https://www.datadoghq.com/blog/datadog-recommended-monitors/ -[15]: /ja/monitors/manage/ -[16]: /ja/monitors/ -[17]: https://www.youtube.com/watch?v=Ma5pr-u9bjk -[18]: /ja/monitors/guide/why-did-my-monitor-settings-change-not-take-effect/ -[19]: /ja/monitors/downtimes/ -[20]: https://www.datadoghq.com/blog/mute-datadog-alerts-planned-downtime/ -[21]: https://www.datadoghq.com/blog/managing-datadog-with-terraform/ -[22]: /ja/api/latest/downtimes/ -[23]: /ja/monitors/guide/prevent-alerts-from-monitors-that-were-in-downtime/ -[24]: /ja/integrations/slack/?tab=slackapplication -[25]: /ja/integrations/pagerduty/ -[26]: /ja/integrations/flowdock/ -[27]: /ja/integrations/servicenow/ -[28]: /ja/integrations/google_hangouts_chat/ -[29]: /ja/integrations/microsoft_teams/ -[30]: /ja/integrations/webhooks/ -[31]: /ja/monitors/notify/ -[32]: https://www.datadoghq.com/blog/send-alerts-sms-customizable-webhooks-twilio/ -[33]: https://www.datadoghq.com/blog/monitoring-101-collecting-data/ -[34]: /ja/dashboards/widgets/timeseries/ -[35]: /ja/dashboards/widgets/free_text/ -[36]: https://learn.datadoghq.com/courses/building-better-dashboards -[37]: /ja/notebooks/ -[38]: https://www.datadoghq.com/blog/network-device-monitoring/ -[39]: https://www.datadoghq.com/blog/template-variable-associated-values/ -[40]: /ja/api/latest/dashboards/ -[41]: https://www.hashicorp.com/resources/configure-observability-as-code-with-terraform-and-datadog -[42]: /ja/dashboards/sharing/ -[43]: /ja/api/latest/embeddable-graphs/ -[44]: /ja/dashboards/guide/embeddable-graphs-with-template-variables/ -[45]: https://www.datadoghq.com/blog/establishing-service-level-objectives/ -[46]: /ja/service_management/service_level_objectives/guide/slo-checklist -[47]: https://www.datadoghq.com/blog/define-and-manage-slos/ -[48]: https://www.datadoghq.com/blog/slo-monitoring-tracking/ -[49]: /ja/api/latest/service-level-objectives/ -[50]: /ja/monitors/types/watchdog/ -[51]: /ja/partners/billing-and-usage-reporting/ \ No newline at end of file From d4bf62ed7912b166efdfe0eafb37781d5c322314 Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:56:22 +0100 Subject: [PATCH 21/29] Deleting translations of content/fr/partners/delivering-value.md --- content/fr/partners/delivering-value.md | 196 ------------------------ 1 file changed, 196 deletions(-) delete mode 100644 content/fr/partners/delivering-value.md diff --git a/content/fr/partners/delivering-value.md b/content/fr/partners/delivering-value.md deleted file mode 100644 index 986a4e1ed0f68..0000000000000 --- a/content/fr/partners/delivering-value.md +++ /dev/null @@ -1,196 +0,0 @@ ---- -description: Étapes recommandées après avoir configuré l'ingestion de données dans - Datadog. -private: true -title: Générer de la valeur ajoutée ---- - -Une fois l'ingestion de données configurée, l'étape suivante consiste à optimiser la valeur ajoutée de ces données pour vos clients. Voici quelques aspects clés sur lesquels vous concentrer. - -## Configurer des monitors et des downtimes - -Les monitors et les alertes permettent d'attirer l'attention des personnes concernées sur des systèmes et des services qui nécessitent d'être inspectés en vue d'une éventuelle intervention. Pour générer des alertes, Datadog propose : -- Des monitors, qui permettent de définir des conditions d'alerte -- Des downtimes, qui permettent de définir des intervalles sur lesquels il n'est pas nécessaire de générer une alerte - -Pour vous familiariser avec le concept général des monitors, consultez les ressources suivantes : -- [Alertes][1] -- [Monitoring 101 : définir des alertes pertinentes][2] (blog). -- [Présentation de la surveillance][3] (formation). - -### Migrer un monitor - -Les fournisseurs de services ont souvent besoin de migrer un client vers Datadog à partir d'une autre plateforme de surveillance ou d'observabilité. Dans ce cas, le premier réflexe est souvent de reprendre les monitors utilisés dans la solution précédente et de les recréer dans Datadog. Toutefois, cette méthode signifie souvent que les fonctionnalités les plus utiles de Datadog ne sont pas utilisées. Il serait particulièrement dommage de ne pas tirer parti de la détection améliorée des problèmes, de la réduction des temps de résolution ou de la limitation des alertes superflues. - -Avant de commencer à migrer vos monitors, passez en revue les alertes et les seuils définis en répondant aux questions suivantes : -- La métrique évolue-t-elle dans le temps ? Un [monitor d'anomalie][4] est peut-être plus adapté. -- La métrique évolue-t-elle en fonction de la charge ? Il est peut-être préférable d'utiliser un [monitor arithmétique][5] afin de combiner une métrique avec une autre métrique qui mesure la charge d'un système. Par exemple, la charge du système est susceptible d'augmenter avec le nombre de personnes qui utilisent un service. -- La valeur absolue de la métrique est-elle moins importante que le taux de variation ? Un [monitor de changement][6] ou un [monitor de prévision][7] est peut-être plus adapté. -- La valeur de la métrique est-elle moins importante que l'écart avec les valeurs d'autres hosts ou entités ? Par exemple, voulez-vous générer une alerte lorsque la latence est élevée sur l'un des nœuds d'un cluster mais pas sur les autres ? Un [monitor de singularité][8] est peut-être plus adapté dans ce cas de figure. -- Une intervention est-elle nécessaire uniquement lorsque plusieurs métriques remplissent certaines conditions ? Utilisez un [monitor composite][9] pour répondre à votre besoin sans avoir à créer de scripts. - -### Gestion automatique des monitors - -En tant que fournisseur de services, vous pouvez optimiser la gestion de vos monitors et de ceux de vos clients via l'une des méthodes suivantes : -- [API Monitors Datadog][10] -- Terraform - - [Comment gérer vos ressources Datadog avec Terraform][11] (Vidéo) - - [Automatiser votre surveillance avec le fournisseur Datadog pour Terraform][12] (guide HashiCorp) - -Assurez-vous de [taguer vos monitors][13] afin faciliter la gestion de grandes quantités de monitors. - -### Monitors recommandés - -Il arrive que vous n'ayez pas beaucoup d'expérience avec certaines technologies utilisées par vos clients. Datadog propose une liste de [monitors recommandés][14] pour vous aider à intégrer ces nouvelles technologies rapidement et en toute confiance. - -Pour en savoir plus sur les monitors, consultez les ressources suivantes : -- [Gérer les monitors][15] -- [Monitors][16] -- [Créer des alertes dynamiques avec des valeurs de tag][17] (Vidéo) -- [Surveiller les modifications de paramètres non appliquées][18] - -### Downtimes - -Les systèmes d'alerte posent souvent un problème majeur : ils génèrent beaucoup d'alertes superflues, ce qui signifie que les équipes finissent souvent par ne plus prêter attention aux notifications. Afin d'atténuer ce problème, il est nécessaire de réduire le nombre de faux positifs, en particulier dans les situations contrôlées telles qu'un arrêt planifié, une maintenance ou une mise à jour. - -Les downtimes de Datadog vous permettent de désactiver vos monitors et ceux de vos clients pendant les périodes de maintenance, qu'elles soient planifiées ou non. - -Pour en savoir plus sur la gestion des downtimes, en particulier les solutions automatiques, consultez les ressources suivantes : -- [Downtime][19] -- [Désactiver les alertes Datadog pendant un downtime planifié][20] (Blog) -- [Gérer Datadog avec Terraform][21] (Blog) -- [API Downtime][22] -- [Empêcher des monitors de générer des alertes pendant un downtime][23] - -### Notifications - -Voici quelques recommandations générales pour les notifications : -- Générez des alertes à volonté, mais notifiez les équipes avec modération -- Notifiez pour informer des symptômes, et non des causes - -Datadog propose de nombreux canaux de notification pour informer les utilisateurs en cas d'alerte importante : - -- Notifications par e-mail -- Intégrations, telles que : - - [Slack][24] - - [PagerDuty][25] - - [Flowdock][26] - - [ServiceNow][27] - - [Google Chat][28] - - [Microsoft Teams][29] - - Et [bien d'autres][19] - -Vous pouvez également invoquer n'importe quelle API REST à l'aide de l'[intégration Webhooks][30] générique. Cette intégration peut être utilisée pour notifier des utilisateurs, mais aussi pour déclencher des workflows de remédiation automatiques. - -Pour en savoir plus sur les notifications, consultez les ressources suivantes : -- [Notifications][31] -- [Envoyer des alertes par SMS à l'aide de Webhooks et de Twilio][32] (Blog) - -## Configurer des visualisations avec les dashboards - -Les visualisations sont idéales pour représenter de façon claire des stacks techniques complexes ainsi que la vaste quantité de métriques et d'événements collectés. Lorsqu'un monitor vous alerte ou alerte l'un de vos clients d'un problème potentiel, il est souvent préférable de commencer par consulter les dashboards pour mener l'enquête. - -### Dashboards prêts à l'emploi - -Dès lors que vous configurez un Agent ou une intégration cloud, Datadog active automatiquement des dashboards prêts à l'emploi pour vous offrir des informations sur le service ou la technologie que vous venez d'intégrer. Vous pouvez également cloner un dashboard prêt à l'emploi pour créer facilement un dashboard personnalisé efficace. - -### Créer des dashboards personnalisés - -Générez de la valeur ajoutée et démarquez-vous de vos concurrents en créant des dashboards spécialement adaptés à des rôles ou des perspectives spécifiques. - -Voici quelques recommandations à prendre en compte lors de la création d'un dashboard : -- Concentrez-vous sur vos métriques opérationnelles au lieu d'ajouter un trop grand nombre de métriques de ressources. Pour comprendre la différence entre les deux types, consultez [Monitoring 101 : Recueillir les bonnes données][33] (article de blog en anglais). -- Utilisez les [superpositions d'événements][34] pour mettre en corrélation vos métriques et vos événements. -- Annotez vos dashboards en ajoutant du [texte libre][35] pour décrire les données affichées et la marche à suivre si le dashboard indique un problème. - -Pour en savoir plus sur les dashboards, consultez les ressources suivantes : -- [Améliorer vos dashboards][36] (Formation) -- Utiliser les [Notebooks Datadog][37] pour explorer vos données et élaborer des dashboards -- [Surveiller des datacenters et des réseaux avec Datadog][38] (Blog) -- [Utiliser les template variables associées][39] (Blog) -- [API Dashboard Datadog][40] -- [Configurer l'observabilité en tant que code avec Terraform et Datadog][41] (Webinar HashiCorp) - -### Visualisations pour les utilisateurs n'ayant pas accès à Datadog - -En fonction de votre modèle opérationnel, il est possible que vos clients n'aient pas besoin d'accéder directement à Datadog. Même s'ils n'ont pas accès à la plateforme, vous avez la possibilité de leur transmettre des visualisations Datadog via l'une des méthodes suivantes : -- [Partage de dashboard][42] : offrez une page de statut à vos clients en leur communiquant un lien d'accès public à un dashboard en lecture seule, ou partagez le dashboard en privé en spécifiant une adresse e-mail. - - En tant que fournisseur de services, vous avez besoin d'une solution gérable à grande échelle. Utilisez les [API de Datadog pour gérer vos dashboards partagés][40] de façon efficace. -- Graphiques intégrables : si vous avez un portail client sur lequel vous souhaitez afficher des données Datadog, les graphiques intégrables sont la solution idéale. Vous pouvez modifier les paramètres pour filtrer les données en fonction de vos besoins. Pour en savoir plus, consultez les ressources suivantes : - - [API Graphiques intégrables][43] - - [Graphiques intégrables avec les template variables][44] - -### Configurer des service-level objectives - -Il est recommandé de communiquer en permanence à vos clients la qualité et le niveau de vos services en faisant preuve de transparence. Les service-level objectives (SLO) constituent le moyen idéal de contrôler et de visualiser la qualité d'un service pour le compte de vos clients, mais aussi d'aider vos clients à mettre en œuvre un reporting basé sur le niveau de service en interne. - -Les ressources suivantes vous aideront à configurer et gérer des SLO : -- Pour commencer, consultez [Service Level Objectives 101 : Mettre en place des SLO efficaces][45] (Blog). -- [Liste de contrôle pour les SLO][46] -- [Conseils à suivre pour gérer vos SLO avec Datadog][47] (Blog) -- [Faire un suivi du statut de tous vos SLO dans Datadog][48] (Blog) -- [API SLO Datadog][49] - -## Utiliser Watchdog - -La fonctionnalité Watchdog permet de détecter de manière algorithmique les problèmes au sein de vos applications et de votre infrastructure. - -Configurez un monitor Watchdog pour votre propre équipe ou votre client et recevez une notification dès que Watchdog détecte une nouvelle irrégularité. - -Pour en savoir plus, consultez la section [Watchdog][50]. - -## Et ensuite ? - -Pour découvrir comment surveiller l'utilisation de Datadog par vos différents clients et l'utilisation globale avec un compte multi-organisations, consultez la section [Données d'utilisation et de facturation][51]. - -[1]: /fr/monitors -[2]: https://www.datadoghq.com/blog/monitoring-101-alerting/ -[3]: https://learn.datadoghq.com/courses/introduction-to-observability -[4]: /fr/monitors/types/anomaly/ -[5]: /fr/monitors/guide/monitor-arithmetic-and-sparse-metrics/ -[6]: /fr/monitors/types/metric/?tab=change -[7]: /fr/monitors/types/forecasts/?tab=linear -[8]: /fr/monitors/types/outlier/?tab=dbscan -[9]: /fr/monitors/types/composite/ -[10]: /fr/api/latest/monitors/ -[11]: https://www.youtube.com/watch?v=Ell_kU4gEGI -[12]: https://learn.hashicorp.com/tutorials/terraform/datadog-provider -[13]: https://www.datadoghq.com/blog/tagging-best-practices-monitors/ -[14]: https://www.datadoghq.com/blog/datadog-recommended-monitors/ -[15]: /fr/monitors/manage/ -[16]: /fr/monitors/ -[17]: https://www.youtube.com/watch?v=Ma5pr-u9bjk -[18]: /fr/monitors/guide/why-did-my-monitor-settings-change-not-take-effect/ -[19]: /fr/monitors/notify/downtimes/ -[20]: https://www.datadoghq.com/blog/mute-datadog-alerts-planned-downtime/ -[21]: https://www.datadoghq.com/blog/managing-datadog-with-terraform/ -[22]: /fr/api/latest/downtimes/ -[23]: /fr/monitors/guide/prevent-alerts-from-monitors-that-were-in-downtime/ -[24]: /fr/integrations/slack/?tab=slackapplication -[25]: /fr/integrations/pagerduty/ -[26]: /fr/integrations/flowdock/ -[27]: /fr/integrations/servicenow/ -[28]: /fr/integrations/google_hangouts_chat/ -[29]: /fr/integrations/microsoft_teams/ -[30]: /fr/integrations/webhooks/ -[31]: /fr/monitors/notify/ -[32]: https://www.datadoghq.com/blog/send-alerts-sms-customizable-webhooks-twilio/ -[33]: https://www.datadoghq.com/blog/monitoring-101-collecting-data/ -[34]: /fr/dashboards/widgets/timeseries/ -[35]: /fr/dashboards/widgets/free_text/ -[36]: https://learn.datadoghq.com/courses/building-better-dashboards -[37]: /fr/notebooks/ -[38]: https://www.datadoghq.com/blog/network-device-monitoring/ -[39]: https://www.datadoghq.com/blog/template-variable-associated-values/ -[40]: /fr/api/latest/dashboards/ -[41]: https://www.hashicorp.com/resources/configure-observability-as-code-with-terraform-and-datadog -[42]: /fr/dashboards/sharing/ -[43]: /fr/api/latest/embeddable-graphs/ -[44]: /fr/dashboards/guide/embeddable-graphs-with-template-variables/ -[45]: https://www.datadoghq.com/blog/establishing-service-level-objectives/ -[46]: /fr/monitors/guide/slo-checklist/ -[47]: https://www.datadoghq.com/blog/define-and-manage-slos/ -[48]: https://www.datadoghq.com/blog/slo-monitoring-tracking/ -[49]: /fr/api/latest/service-level-objectives/ -[50]: /fr/monitors/types/watchdog/ -[51]: /fr/partners/billing-and-usage-reporting/ \ No newline at end of file From 7ed95da23bfac3d56b084229457856d17838deae Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:56:36 +0100 Subject: [PATCH 22/29] Deleting translations of content/es/partners/delivering-value.md --- content/es/partners/delivering-value.md | 195 ------------------------ 1 file changed, 195 deletions(-) delete mode 100644 content/es/partners/delivering-value.md diff --git a/content/es/partners/delivering-value.md b/content/es/partners/delivering-value.md deleted file mode 100644 index f0c478fbe9f19..0000000000000 --- a/content/es/partners/delivering-value.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -description: Pasos recomendados después de que los datos fluyan hacia Datadog. -private: true -title: Aportar valor ---- - -Una vez configurada la ingesta de datos, puedes tomar varias medidas adicionales para maximizar el valor para tus clientes. He aquí algunas áreas clave en las que centrarse. - -## Configuración de monitores y caída del sistema - -Los monitores y las alertas llaman la atención de las personas sobre determinados sistemas y servicios que requieren inspección e intervención. Para generar alertas, Datadog ofrece: -- Monitores: definiciones de las condiciones de alerta -- Caída del sistema - periodos de tiempo en los que deben activarse o suprimirse las alertas - -Para familiarizarte con el concepto de monitores en general, consulta los siguientes recursos: -- [Alertar][1] -- [Monitorización 101 - Alertar sobre qué asuntos][2] (blog). -- [Introducción a la Monitorización][3] (Entrenamiento). - -### Migraciones de monitores - -A menudo, los proveedores de servicios necesitan migrar un cliente desde una plataforma de monitorización o de observabilidad diferente a Datadog. En tales casos, podría parecer lógico replicar cualquier monitor de la solución anterior en Datadog. Este enfoque a menudo hace que muchas de las características más útiles de Datadog queden sin utilizar. En particular, no querrás perderte funciones que mejoran los tiempos de detección y de resolución de problemas o reducen la fatiga por alertas. - -Antes de iniciar un proyecto de migración, revisa las definiciones de alerta y umbral existentes para responder a las siguientes preguntas: -- ¿Tiene la métrica una variación basada en el tiempo? Un [monitor de anomalías][4] podría ser un mejor enfoque. -- ¿Tiene la métrica una variación basada en la carga? Un [monitor aritmético][5] podría ser el mejor enfoque mediante la combinación de una métrica con una métrica que indique la carga. Por ejemplo, la carga de los sistemas podría ser mayor si hay más usuarios utilizando un servicio. -- ¿Es el valor absoluto de la métrica menos importante que la tasa de cambio? Un [cambio de monitor][6] o un [monitor de predicción][7] podría ser el mejor enfoque. -- ¿Es el valor de la propia métrica menos importante que si es diferente del valor para otros hosts o entidades? Por ejemplo, ¿experimenta un nodo de clúster una latencia alta mientras que otros nodos no? El [monitor outlier][8] es el mejor enfoque en este escenario. -- ¿Sólo una combinación de varias métricas presenta una situación procesable? Los [monitores compuestos][9] ofrecen una solución que no requiere la provisión de scripts. - -### Gestión de monitores mediante programación - -Como proveedor de servicios, la gestión de monitores para ti y tus clientes se realiza mejor mediante programación a través de una de las siguientes vías: -- [API de monitores Datadog][10] -- Terraform - - [Cómo gestionar los recursos de Datadog con Terraform][11] (vídeo) - - [Automatizar la monitorización con el proveedor Terraform Datadog][12] (Tutorial de HashiCorp) - -Asegúrate de [etiquetar monitores][13] para facilitar la gestión de un gran número de monitores. - -### Monitores recomendados - -Es posible que tus clientes utilicen tecnologías con las que tú no tengas mucha experiencia. Datadog ofrece [Monitores recomendados][14] que te ayudarán a incorporar nuevas tecnologías con rapidez y confianza. - -Para saber más sobre monitores, consulta: -- [Gestionar monitores][15] -- [Monitores][16] -- [Crear alertas dinámicas mediante valores de etiquetas (tags)][17] (vídeo) -- [Los cambios de configuración de monitores no surten efecto][18] - -### Caída del sistema - -Un problema habitual de los monitores y las alertas es la fatiga por alertas, en la que una sobreabundancia de alarmas o notificaciones provoca la insensibilización a las alarmas. Una forma de combatir la fatiga por alertas es limitar el número de alarmas falsas positivas. Esto es especialmente pertinente en situaciones controladas como paradas planificadas del sistema, mantenimiento o ventanas de actualización. - -Las caídas del sistema de Datadog te ofrecen a ti y a tus clientes una forma de silenciar monitores durante los periodos de mantenimiento planificado (o ad hoc). - -Para saber más sobre la gestión de las caídas del sistema, especialmente mediante programación, consulta: -- [Caída del sistema][19] -- [Silenciar alertas de Datadog para caídas del sistema programadas][20] (Blog) -- [Gestión de Datadog con Terraform][21] (Blog) -- [API de caída del sistema][22] -- [Evitar alertas de monitores que estaban en caída del sistema][23] - -### Notificaciones - -Algunas directrices generales para notificaciones: -- Alertar liberalmente; avisar juiciosamente -- Página sobre los síntomas, más que sobre las causas - -Datadog ofrece varios canales a través de los cuales tú o tus clientes pueden notificar a los usuarios alertas importantes: - -- Notificaciones por correo electrónico -- integraciones, como: - - [Slack][24] - - [PagerDuty][25] - - [Flowdock][26] - - [ServiceNow][27] - - [Google Chat][28] - - [Microsoft Teams][29] - - Y [muchas más][19] - -También puedes invocar cualquier API REST con la [integración de Webhooks][30] genérica. Puedes utilizar una integración de Webhooks no sólo para notificar a los usuarios, sino también para activar flujos de trabajo de corrección automáticos. - -Para saber más sobre notificaciones, consulta: -- [Notificaciones][31] -- [Enviar alertas por SMS con Webhooks y Twilio][32] (Blog) - -## Configuración de visualizaciones con dashboards - -Las visualizaciones son una excelente manera de ofrecer a tus clientes una imagen clara de los complejos stacks tecnológicos y de la abundancia de métricas y eventos que se están recopilando. Los dashboards son un punto de partida natural para investigar un posible problema que te hayan notificado a ti o a tu cliente a través de un monitor. - -### Dashboards listos para usar - -En el momento en que se configura una integración del Agent o Cloud, Datadog activa automáticamente dashboards listos para usar para la nueva tecnología o servicio integrado, lo que proporciona información inmediata. También puedes clonar un dashboard listo para usar, lo que te proporciona un excelente punto de partida para un dashboard personalizado. - -### Crear dashboards personalizados - -Puedes aportar un valor añadido y distinguirte de tus competidores ofreciendo una perspectiva centrada en la empresa, adaptada a diferentes personas. - -Estas son algunas de las mejores prácticas de dashboards que debes tener en cuenta a la hora de crear tus dashboards: -- Céntrate en las métricas del trabajo y no en demasiadas métricas de recursos. Para entender la diferencia, consulta [Monitorización 101: Recopilar los datos adecuados][33] (blog). -- Aprovecha [superposiciones de eventos][34] para correlacionar métricas y eventos. -- Anota los dashboards con [información de texto libre][35] sobre qué datos se muestran y qué hacer en caso de que el dashboard indique un problema. - -Para saber más sobre dashboards, consulta: -- [Crear mejores dashboards][36] (Entrenamiento) -- Utiliza la función [Datadog Notebooks ][37] para recopilar datos de forma exploratoria y redactar dashboards. -- [Centros de datos y redes de monitores con Datadog][38] (Blog) -- [Utilizar variables de plantillas asociadas][39] (Blog) -- [La API Datadog Dashboard ][40] -- [Configurar Observability como un código con Terraform y Datadog][41] (webinar de HashiCorp) - -### Visualizaciones para usuarios sin acceso a Datadog - -En función de tu modelo de negocio, es posible que tus clientes no necesiten acceder a Datadog. Sin embargo, podrías desear proporcionar visualizaciones de Datadog a tus clientes. Dispones de las siguientes opciones para proporcionar visualizaciones de Datadog: -- [Compartir dashboards][42]: Proporciona una página de estado a tus clientes compartiendo una URL pública a un dashboard de sólo lectura o comparte el dashboard de forma privada utilizando una dirección de correo electrónico individual. - - Como proveedor de servicios, tu empresa necesita poder escalar. [Gestionar los dashboards compartidos con las API de Datadog][40] es el enfoque más eficiente. -- Gráficos insertables: Si tienes un portal de clientes en el que deseas presentar información de Datadog, los gráficos insertables son la solución. Mediante parámetros, puedes filtrar los datos según tus necesidades. Para obtener más información, consulta: - - [API de gráficos insertables][43] - - [Gráficos insertables con variables de plantillas][44] - -### Configurar objetivos de nivel de servicio - -Es una buena idea presentar continuamente la calidad y el nivel de tus servicios a tus clientes de forma transparente. Los objetivos de nivel de servicio (SLOs) son una excelente manera de monitorizar y visualizar la calidad de los servicios en nombre de tus clientes y también contribuyen a que tus clientes implementen informes basados en el nivel de los servicios de manera interna. - -El siguiente material puede serte útil a la hora de configurar y gestionar los SLOs: -- Para empezar, consulta [Objetivos de nivel de servicio (SLOs) 101: Establecer SLOs eficaces][45] (Blog). -- [Lista de verificación de SLOs][46] -- [Mejores prácticas para gestionar tus SLOs con Datadog][47] (Blog) -- [Rastrea el estado de todos tus SLOs en Datadog][48] (Blog) -- [La API de SLOs de Datadog][49] - -## Utilizar Watchdog - -Watchdog es una función algorítmica que detecta automáticamente posibles problemas de la aplicación y la infraestructura. - -Configura un monitor de Watchdog para tu propio personal o tu cliente con una notificación cada vez que Watchdog haya detectado una nueva irregularidad. - -Para obtener más información, consulta [Watchdog][50]. - -## ¿Qué es lo que sigue? - -Descubre cómo monitorizar el uso de clientes individuales y agregado de la plataforma Datadog en configuraciones de cuentas de varias organizaciones con [Informe de facturación y uso][51]. - -[1]: /es/monitors -[2]: https://www.datadoghq.com/blog/monitoring-101-alerting/ -[3]: https://learn.datadoghq.com/courses/introduction-to-observability -[4]: /es/monitors/types/anomaly/ -[5]: /es/monitors/guide/monitor-arithmetic-and-sparse-metrics/ -[6]: /es/monitors/types/metric/?tab=change -[7]: /es/monitors/types/forecasts/?tab=linear -[8]: /es/monitors/types/outlier/?tab=dbscan -[9]: /es/monitors/types/composite/ -[10]: /es/api/latest/monitors/ -[11]: https://www.youtube.com/watch?v=Ell_kU4gEGI -[12]: https://learn.hashicorp.com/tutorials/terraform/datadog-provider -[13]: https://www.datadoghq.com/blog/tagging-best-practices-monitors/ -[14]: https://www.datadoghq.com/blog/datadog-recommended-monitors/ -[15]: /es/monitors/manage/ -[16]: /es/monitors/ -[17]: https://www.youtube.com/watch?v=Ma5pr-u9bjk -[18]: /es/monitors/guide/why-did-my-monitor-settings-change-not-take-effect/ -[19]: /es/monitors/downtimes/ -[20]: https://www.datadoghq.com/blog/mute-datadog-alerts-planned-downtime/ -[21]: https://www.datadoghq.com/blog/managing-datadog-with-terraform/ -[22]: /es/api/latest/downtimes/ -[23]: /es/monitors/guide/prevent-alerts-from-monitors-that-were-in-downtime/ -[24]: /es/integrations/slack/?tab=slackapplication -[25]: /es/integrations/pagerduty/ -[26]: /es/integrations/flowdock/ -[27]: /es/integrations/servicenow/ -[28]: /es/integrations/google_hangouts_chat/ -[29]: /es/integrations/microsoft_teams/ -[30]: /es/integrations/webhooks/ -[31]: /es/monitors/notify/ -[32]: https://www.datadoghq.com/blog/send-alerts-sms-customizable-webhooks-twilio/ -[33]: https://www.datadoghq.com/blog/monitoring-101-collecting-data/ -[34]: /es/dashboards/widgets/timeseries/ -[35]: /es/dashboards/widgets/free_text/ -[36]: https://learn.datadoghq.com/courses/building-better-dashboards -[37]: /es/notebooks/ -[38]: https://www.datadoghq.com/blog/network-device-monitoring/ -[39]: https://www.datadoghq.com/blog/template-variable-associated-values/ -[40]: /es/api/latest/dashboards/ -[41]: https://www.hashicorp.com/resources/configure-observability-as-code-with-terraform-and-datadog -[42]: /es/dashboards/sharing/ -[43]: /es/api/latest/embeddable-graphs/ -[44]: /es/dashboards/guide/embeddable-graphs-with-template-variables/ -[45]: https://www.datadoghq.com/blog/establishing-service-level-objectives/ -[46]: /es/service_management/service_level_objectives/guide/slo-checklist -[47]: https://www.datadoghq.com/blog/define-and-manage-slos/ -[48]: https://www.datadoghq.com/blog/slo-monitoring-tracking/ -[49]: /es/api/latest/service-level-objectives/ -[50]: /es/monitors/types/watchdog/ -[51]: /es/partners/billing-and-usage-reporting/ \ No newline at end of file From 26251a3be3288b264a8b1b6c8951f3da124c95fa Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:56:50 +0100 Subject: [PATCH 23/29] Deleting translations of content/ko/partners/delivering-value.md --- content/ko/partners/delivering-value.md | 195 ------------------------ 1 file changed, 195 deletions(-) delete mode 100644 content/ko/partners/delivering-value.md diff --git a/content/ko/partners/delivering-value.md b/content/ko/partners/delivering-value.md deleted file mode 100644 index 6dcdd3f5a98e1..0000000000000 --- a/content/ko/partners/delivering-value.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -description: Datadog로 데이터가 전송되기 시작하면 실행해야 할 단계 -private: true -title: 가치 제공하기 ---- - -데이터 수집을 설정한 후, 클라이언트에게 최대로 가치를 제공하기 위해 실행할 수 있는 추가 단계가 몇 가지 있습니다. 초점을 맞춰야 할 핵심 영역은 다음과 같습니다. - -## 모니터와 다운타임 설정하기 - -모니터와 알림을 통해 조사와 개입이 필요한 특정 시스템과 서비스를 살펴볼 수 있습니다. Datadog에서는 다음 알림을 생성할 수 있습니다. -- 모니터 - 알림 조건 정의 -- 다운타임 - 알림을 보내거나 취소할 기간 - -모니터 개념과 친숙해지려면 다음 리소스를 참고하세요. -- [알림][1] -- [모니터링 101 - 중요한 사항 알림][2](블로그) -- [모니터링 소개][3](교육) - -### 모니터 마이그레이션하기 - -서비스 공급자가 다른 모니터링이나 가시화 플랫폼에서 Datadog로 마이그레이션해야 할 경우가 자주 있습니다. 이 때 이전 솔루션에서 Datadog로 모니터를 그대로 복제하면 된다고 생각하는 경우가 많습니다. 그러나 이 방법으로는 유용한 Datadog 기능을 활용하지 못할 수 있습니다. 특히 문제를 더 빨리 감지하고 문제 해결 시간 및 알림 피로를 줄일 수 있는 기능을 자칫 놓칠 수 있습니다. - -마이그레이션 프로젝트를 시작하기 전에 기존 알림과 임계값 정의를 재확인하고 다음 질문에 답해보세요. -- 메트릭에 시간 기반 변수가 있나요? [이상 값 모니터][4]가 좋은 대안이 될 수 있습니다. -- 메트릭에 로드 기반 변수가 있나요? 로드 표시 메트릭과 메트릭을 조합해 [산술 모니터][5]를 사용하는 것을 추천합니다. 예를 들어 서비스를 사용하는 사용자가 많으면 시스템 로드가 더 많아질 수 있습니다. -- 메트릭 절대값보다 변화율이 더 중요하나요? [변화 모니터][6]이나 [예측 모니터][7]가 좋은 방법이 될 수 있습니다. -- 메트릭 자체 값보다 다른 호스트나 엔터티 값과 다르다는 점이 더 중요하나요? 예를 들어 클러스터에 있는 노드 하나가 다른 노드에 비해 대기 시간이 더 긴가요? 이 경우 [이상값 모니터][8]를 사용하면 좋습니다. -- 여러 메트릭을 조합해야만 조치할 상황이 보이나요? [복합 모니터][9]을 통해 스크립팅 없이 문제를 해결할 수 있습니다. - -### 프로그래밍 방식 모니터 관리 - -서비스 공급자는 다음 중 하나의 방법으로 프로그래밍 방식을 통해 사용자와 클라이언트의 모니터를 최적으로 관리할 수 있습니다. -- [Datadog 모니터 API][10] -- Terraform - - [Terraform으로 Datadog 리소스 관리하는 방법][11](비디오) - - [Terraform Datadog 공급자로 모니터링 자동화하기][12](HashiCorp 튜토리얼) - -[모니터를 태그][13]해 대량의 모니터도 쉽게 관리할 수 있도록 하세요. - -### 추천 모니터 - -클라이언트가 사용하는 기술이 내게 익숙지 않은 것일 수 있습니다. Datadog에서는 [추천 모니터][14]를 통해 새 기술을 빠르고 자신 있게 습득할 수 있도록 돕습니다. - -모니터에 대해 더 알아보려면 다음을 참고하세요. -- [모니터 관리][15] -- [모니터][16] -- [태그 값으로 동적 알람 생성하기][17](비디오) -- [모니터 설정 변경 사항이 적용되지 않음][18] - -### 다운타임
- -모니터와 알림과 관련한 가장 일반적인 문제는 알림 피로입니다. 알림 피로는 알람이나 알림이 너무 많아서 알람을 무시하게 되는 현상을 뜻합니다. 알림 피로를 줄이는 방법의 하나는 가양성 알람 수를 제한하는 것입니다. 계획된 시스템 중단, 유지보수, 또는 Windows 업그레이드와 같은 통제된 환경일 경우 특히 이 방법을 사용하는 것이 좋습니다. - -Datadog의 다운타임을 이용하면 계획된(또는 일시적인) 유지보수가 진행되는 동안 모니터 알림을 음소거할 수 있습니다. - -다운타임 관리, 특히 프로그래밍 방식의 다운타임 관리에 대해 더 알아보려면 다음을 참고하세요. -- [다운타임][19] -- [계획된 다운타임 동안 Datadog 알림 음소거하기][20](블로그) -- [Terraform으로 Datadog 관리하기][21](블로그) -- [다운타임 API][22] -- [다운타임 상태인 모니터 알림 예방하기][23] - -### 알림 - -다음은 알림과 관련한 일반 지침입니다. -- 알림은 많이 보내되 호출은 변별력 있게 -- 원인이 아니라 증상에 따라 호출 - -Datadog에서는 다양한 채널을 통해 중요한 알림을 사용자와 클라이언트에게 보냅니다. - -- 이메일 알림 -- 다음 통합에서 알림: - - [Slack][24] - - [PagerDuty][25] - - [Flowdock][26] - - [ServiceNow][27] - - [Google Chat][28] - - [Microsoft Teams][29] - - [그 외 기타][19] - -또한 일반 [Webhooks 통합][30]을 사용해 REST API를 호출할 수 있습니다. Webhooks 통합은 사용자에게 알림을 보낼 때 사용할 뿐만 아니라 자동 수정 워크플로우를 트리거할 때도 사용할 수 있습니다. - -알림에 관해 더 알아보려면 다음을 참고하세요. -- [알림][31] -- [Webhooks와 Twilio로 SMS 알림 보내기][32](블로그) - -## 대시보드로 가시화 설정하기 - -복잡한 기술 스택과 수집 중인 다양한 메트릭과 이벤트를 가시화하면 정보를 명확히 얻을 수 있습니다. 이에 따라 모니터로 발견한 잠재적인 문제를 조사할 때 대시보드에서 시작하면 좋습니다. - -### 기본 제공 대시보드 - -에이전트나 클라우드 통합이 설정되면 Datadog에서 자동으로 새 통합 서비스와 기술의 기본 제공 대시보드가 활성화되어 즉각적으로 유용한 인사이트를 얻을 수 있습니다. 또 기본 제공 대시보드를 복제해 커스텀 대시보드를 만들 수 있습니다. - -### 커스텀 대시보드 구축하기 - -비즈니스 관점을 두드러지게 하는 추가 값을 넣어 경쟁사와 차별화하고 여러 페르소나에 맞출 수 있습니다. - -다음은 대시보드를 구축할 때 고려할 대시보드 모범 사례이니 참고하세요. -- 리소스 메트릭을 많이 사용하기보다는 작업 메트릭에 초점을 맞추세요. 이 차이에 대해 이해하려면 [모니터링 101: 올바른 데이터 수집하기][33](블로그)를 참고하세요. -- [이벤트 오버레이][34]를 사용해 메트릭과 이벤트의 상관 관계를 확인하세요. -- 대시보드에 [자유 형식 텍스트 정보][35]로 주석을 달아 표시된 데이터가 무엇인지, 대시보드에 문제가 나타났을 때 어떻게 조치할 지를 남기세요. - -대시보드에 대해 더 알아보려면 다음을 참고하세요. -- [더 나은 대시보드 구축하기][36](교육) -- [Datadog Notebooks][37] 기능을 사용해 데이터를 실험적으로 수집하고 대시보드를 만들어 보세요. -- [Datadog로 데이터센터와 네트워크 모니터링하기][38](블로그) -- [연결된 템플릿 변수 사용하기][39](블로그) -- [Datadog 대시보드 API][40] -- [Terraform 및 Datadog를 사용해 코드로 가시성 구성하기][41](HashiCorp 웨비나) - -### Datadog에 접근할 수 없는 사용자를 위해 가시화하기 - -비즈니스 모델에 따라 클라이언트가 Datadog에 접근할 수 없는 경우가 있습니다. 이런 클라이언트에게 Datadog 가시화 정보를 제공하고 싶을 경우, 다음 Datadog 가시화 옵션 중 하나를 선택할 수 있습니다. -- [대시보드 공유][42]: 읽기 전용 대시보드의 공용 URL을 공유하거나 개인 이메일 주소를 사용해 개인적으로 대시보드를 공유해 클라이언트에게 상태 페이지를 제공할 수 있습니다. - - 서비스 공급자는 비즈니스 확장성을 갖춰야 합니다. [Datadog의 API를 사용해 공유된 대시보드를 관리][40]하는 것이 가장 효과적인 방법입니다. -- 임베드할 수 있는 그래프: Datadog 정보를 보여주고 싶은 클라이언트 포털이 있을 경우, 임베드할 수 있는 그래프를 사용할 수 있습니다. 파라미터를 사용해 필요한 데이터를 필터링할 수 있습니다. 자세한 정보는 다음을 참고하세요. - - [임베드할 수 있는 그래프 API][43] - - [템플릿 변수가 있고 임베드할 수 있는 그래프][44] - -### 서비스 수준 목표 설정하기 - -클라이언트에게 서비스 품질과 수준을 지속적이고 투명하게 보여 주는 것이 좋습니다. 서비스 수준 목표(SLO)는 클라이언트 대신 서비스 품질을 모니터링 및 가시화해주고, 클라이언트가 서비스 수준 기반의 내부 보고를 구현하도록 도와줍니다. - -다음은 SLO를 설정하고 관리할 때 도움이 되는 자료입니다. -- 시작하려면 [서비스 수준 목표 101: 효과적인 SLO 수립][45](블로그)를 참고하세요. -- [SLO 체크리스트][46] -- [Datadog로 SLO 관리하기 모범 사례][57](블로그) -- [Datadog에서 SLO 상태 모두 추적하기][48](블로그) -- [Datadog SLO API][49] - -## Watchdog 사용하기 - -Watchdog는 애플리케이션과 인프라스트럭처의 잠재적 문제를 자동으로 감지하는 알고리듬 기능입니다. - -사용자나 클라이언트가 Watchdog 모니터를 설정하면 새 이상 신호가 감지될 때 알림을 받을 수 있습니다. - -자세한 정보는 [Watchdog][50]을 참고하세요. - -## 다음 단계 - -[빌링 및 사용량 보고][51]를 통해 여러 조직 계정 설정에서 개별 클라이언트 및 Datadog 플랫폼 사용량 합계를 모니터링하는 방법을 알아보세요. - -[1]: /ko/monitors -[2]: https://www.datadoghq.com/blog/monitoring-101-alerting/ -[3]: https://learn.datadoghq.com/courses/introduction-to-observability -[4]: /ko/monitors/types/anomaly/ -[5]: /ko/monitors/guide/monitor-arithmetic-and-sparse-metrics/ -[6]: /ko/monitors/types/metric/?tab=change -[7]: /ko/monitors/types/forecasts/?tab=linear -[8]: /ko/monitors/types/outlier/?tab=dbscan -[9]: /ko/monitors/types/composite/ -[10]: /ko/api/latest/monitors/ -[11]: https://www.youtube.com/watch?v=Ell_kU4gEGI -[12]: https://learn.hashicorp.com/tutorials/terraform/datadog-provider -[13]: https://www.datadoghq.com/blog/tagging-best-practices-monitors/ -[14]: https://www.datadoghq.com/blog/datadog-recommended-monitors/ -[15]: /ko/monitors/manage/ -[16]: /ko/monitors/ -[17]: https://www.youtube.com/watch?v=Ma5pr-u9bjk -[18]: /ko/monitors/guide/why-did-my-monitor-settings-change-not-take-effect/ -[19]: /ko/monitors/downtimes/ -[20]: https://www.datadoghq.com/blog/mute-datadog-alerts-planned-downtime/ -[21]: https://www.datadoghq.com/blog/managing-datadog-with-terraform/ -[22]: /ko/api/latest/downtimes/ -[23]: /ko/monitors/guide/prevent-alerts-from-monitors-that-were-in-downtime/ -[24]: /ko/integrations/slack/?tab=slackapplication -[25]: /ko/integrations/pagerduty/ -[26]: /ko/integrations/flowdock/ -[27]: /ko/integrations/servicenow/ -[28]: /ko/integrations/google_hangouts_chat/ -[29]: /ko/integrations/microsoft_teams/ -[30]: /ko/integrations/webhooks/ -[31]: /ko/monitors/notify/ -[32]: https://www.datadoghq.com/blog/send-alerts-sms-customizable-webhooks-twilio/ -[33]: https://www.datadoghq.com/blog/monitoring-101-collecting-data/ -[34]: /ko/dashboards/widgets/timeseries/ -[35]: /ko/dashboards/widgets/free_text/ -[36]: https://learn.datadoghq.com/courses/building-better-dashboards -[37]: /ko/notebooks/ -[38]: https://www.datadoghq.com/blog/network-device-monitoring/ -[39]: https://www.datadoghq.com/blog/template-variable-associated-values/ -[40]: /ko/api/latest/dashboards/ -[41]: https://www.hashicorp.com/resources/configure-observability-as-code-with-terraform-and-datadog -[42]: /ko/dashboards/sharing/ -[43]: /ko/api/latest/embeddable-graphs/ -[44]: /ko/dashboards/guide/embeddable-graphs-with-template-variables/ -[45]: https://www.datadoghq.com/blog/establishing-service-level-objectives/ -[46]: /ko/service_management/service_level_objectives/guide/slo-checklist -[47]: https://www.datadoghq.com/blog/define-and-manage-slos/ -[48]: https://www.datadoghq.com/blog/slo-monitoring-tracking/ -[49]: /ko/api/latest/service-level-objectives/ -[50]: /ko/monitors/types/watchdog/ -[51]: /ko/partners/billing-and-usage-reporting/ \ No newline at end of file From cb3db2d990dd0ff9758c720e1536324cf5a371f0 Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:57:03 +0100 Subject: [PATCH 24/29] Deleting translations of content/ja/partners/data-intake.md --- content/ja/partners/data-intake.md | 204 ----------------------------- 1 file changed, 204 deletions(-) delete mode 100644 content/ja/partners/data-intake.md diff --git a/content/ja/partners/data-intake.md b/content/ja/partners/data-intake.md deleted file mode 100644 index b7f6f96e7232e..0000000000000 --- a/content/ja/partners/data-intake.md +++ /dev/null @@ -1,204 +0,0 @@ ---- -description: Datadog にデータを取り込む方法と、クライアントの環境で満たす必要のある前提条件。 -private: true -title: データの取り込み ---- - -下地ができたので、いよいよ Datadog にデータを取り込みます。 - -当初、このフェーズの目的は、あなたやクライアントにすぐに価値を提供するためのデータを集めることであるべきです。しかし、長期的には、以下のような質問をすることで、常に環境の変化を評価する継続的なプロセスであると考えるべきです。 -- あなたやクライアントは、新しいテクノロジーを採用しましたか？ -- あなたやクライアントは、新しいプロセスを導入しましたか？ -- Datadog は、あなたが使うことができる新しい製品機能を導入しましたか？ - -これらの質問を定期的に検討し、必要なテレメトリーがすべて Datadog に取り込まれていることを確認します。 - -## インテグレーション - -インテグレーションを通じて、クライアントに即座に価値を提供することができます。Datadog は、幅広いテクノロジーからメトリクスやログを収集する {{< translate key="integration_count" >}} のインテグレーションを提供しています。 - -インテグレーションには、大きく分けて 3 つのカテゴリーがあります。 -- クラウドサービスインテグレーション -- Datadog Agent と Agent ベースのインテグレーション -- API / ライブラリインテグレーションとカスタムチェック - -インテグレーションの種類については、[インテグレーションの紹介][1]を参照してください。 - -## クラウドサービスインテグレーション - -クラウドサービスや「クローラー」ベースのインテグレーションは、認証された接続を使用して、API を使用してクラウドサービスからインフラストラクチャー情報、メトリクス、ログ、およびイベントを収集します。 - -クラウドサービスインテグレーションは、通常数分で設定でき、メトリクスやイベントが Datadog に流れ込むため、すぐに価値を発揮します。 - -**注**: クラウドサービスインテグレーションは、大量のデータを生成するため、Datadog とクラウドプロバイダーの両方から請求の影響を受ける可能性があります。 - -ほとんどのシナリオにおいて、インフラストラクチャーや、特にこれらの環境で実行されているアプリケーションを完全に理解するためには、クラウドサービスインテグレーションを使用するだけでは不十分であることに注意してください。Datadog では、クラウドサービスインテグレーションに加え、あらゆるデータ収集手段を活用することを推奨しています。 - -クラウド環境のモニタリングについて、詳しくはこちらをご覧ください。 -- [クラウドの監視][2] (電子書籍) -- [AWS クラウドモニタリング入門][3] (ブログ) -- [Cloud クラウドモニタリング入門][4] (ブログ) -- [Azure クラウドモニタリング入門][5] (ブログ) - -## Datadog Agent と Agent ベースのインテグレーション - -Datadog Agent は、ホスト上で動作し、Datadog に送信するイベントやメトリクスを収集するソフトウェアです。Agent は、一般的に使用されている全てのプラットフォームで利用可能です。Agent 自体は、実行中のホストに関する多くのメトリクス (CPU、メモリ、ディスク、ネットワークメトリクスなど) を収集できますが、Agent の本当の強みはそのインテグレーションにあります。 - -Agent ベースのインテグレーションにより、Agent は、ホスト上で直接、またはホスト上で実行されているコンテナで実行されているアプリケーションやテクノロジーからメトリクス、ログ、トレース、およびイベントを収集することができます。 - -インテグレーションと Datadog Agent について、詳しくはこちらをご覧ください。 -- [Datadog インテグレーション一覧][6] -- [Datadog Agent][7] -- [Agent の概要][8] - -## API / ライブラリインテグレーションとカスタムチェック - -Datadog はスケーラビリティと拡張機能に重点を置いており、以下のような状況でプラットフォームを拡張するための API や SDK をいくつか提供しています。 -- IoT デバイスなどでは、セキュリティなどの制約により Agent をインストールできない場合がある。 -- Datadog Agent とそのインテグレーションが持つ機能が、技術や要件をカバーしていない。 - -このような場合、API を使用することで、クライアントの観測可能性プラットフォームに関連するテレメトリーをキャプチャすることができます。 - -サービスプロバイダーとして最も関心の高い API は、次の 3 つでしょう。 -- データ取り込みのための公開 API -- カスタムチェック -- Agent 上のデータ取り込みのためのローカル API - -### データ取り込みのための公開 API - -クラウドサービスインテグレーションや Agent を利用できない、あるいは利用したくない場合、以下の API を利用するとデータ取り込みに便利です。 - -- ログは、Datadog の[ログ取り込みエンドポイント][9]に直接転送することが可能です。 -- メトリクスは、Datadog の[メトリクス API][10] に直接転送することが可能です。 -- イベントは、Datadog の[イベント API][11] に直接転送することが可能です。 -- トレースは、Datadog の[トレース/スパン API][12] に直接転送することが可能です。 - -### カスタムチェック - -Datadog は {{< translate key="integration_count" >}} のインテグレーションを提供していますが、クライアントは、既存のどのインテグレーションでもカバーできないカスタムアプリケーションを実行している場合があります。これらのアプリケーションを監視するために、クライアントは Agent を使用してカスタムチェックを実行することができます。 - -詳しくは、[カスタムチェック][13]をご覧ください。 - -### Agent 上のデータ取り込みのためのローカル API - -Datadog Agent には、メトリクス集計サービスである DogStatsD がバンドルされており、UDP を使用してデータを受け付けます。DogStatsD は、カスタムチェックがユースケースに合わず、アプリケーションのための既存のインテグレーションがない場合の良い代替手段です。例えば、cron ジョブからイベントとメトリクスデータを収集するために DogStatsD を使うことができますが、おそらくそのジョブは独自のログファイルを持っていないでしょう。 - -DogStatsD のエンドポイントを使用するか、Datadog のクライアントライブラリを使用して DogStatsD へのメトリクスやイベントの送信を容易にすることができます。 - -詳しくは、こちらをご覧ください。 -- [イベントの送信][14] -- [カスタムメトリクスの送信][15] -- [ライブラリ][16] -- [API リファレンス][17] - -## タグ付け戦略 - -Datadog の全機能を利用するためには、優れたタグ付け戦略が不可欠です。 - -タグはデータに付けられるラベルで、Datadog 全体でデータのフィルタリング、グループ化、相関付けを行うことができます。タグは、Datadog の異なるテレメトリータイプを結合し、メトリクス、トレース、ログ間の相関とアクションの呼び出しを可能にします。これは、予約されたタグキーで実現されます。 - -一貫したタグ付け戦略を事前に設定することで、Datadog の実装を成功させ、最終的にクライアントの価値実現を高めることができます。 - -タグ付けを考える際には、以下のような点に配慮してください。 -- **テクノロジー**: チーム間やクライアント間で、同じ技術の使用状況を比較することができます。 -- **環境**: テスト環境、本番環境、その他の環境間のパフォーマンスを比較することができます。 -- **場所**: 特定のデータセンターやクラウドサービスプロバイダーのアベイラビリティゾーンに関連する問題を理解することができます。 -- **ビジネスサービス**: 技術に関係なく、ビジネスサービスの構成要素をフィルターにかけることができます。 -- **役割**: ビジネスサービスにおいて、エンティティがどのような役割を担っているかを把握することができます。 -- **責任**: 担当チームがすべてのリソースをフィルターできるようにし、他のユーザーやチームが特定のサービスを担当するチームを識別できるようにします。 - -[タグ入門][18]を読んで、成功するための準備をしましょう。 - -タグ付けとタグ付け戦略について、詳しくはこちらをご覧ください。 -- インフラストラクチャーとアプリケーションにタグを付けるためのベストプラクティス][19] (ブログ) -- [タグ付けのベストプラクティス][20] (トレーニング) -- [統合サービスタグ付け][21] -- [Kubernetes タグ抽出][22] -- [AWS タグ付け][23] (AWS ドキュメント) -- [サーバーレスタグ付け][24] -- [ライブコンテナタグ付け][25] - -## Agent のロールアウト - -ここでは、Agent を展開するための主なフェーズを紹介します。 -- Agent デプロイのための前提条件 -- 既存インフラストラクチャーへの Agent の初期デプロイ -- 新インフラストラクチャーのプロビジョニング -- 継続的なプロビジョニングプロセスの監視 - -### Agent デプロイのための前提条件 - -プラットフォームやオペレーティングシステムによっては、Agent の前提条件が異なる場合があります。これらの要件については、[Agent の公式ドキュメント][7]を参照してください。 - -どのプラットフォームでも Agent の主な前提条件は、ネットワーク接続性です。トラフィックは常に Agent から Datadog へ開始されます。Datadog から Agent に戻るセッションが開始されることはありません。稀なケースを除き、インバウンド接続 (ローカルファイアウォールによる制限) は、Agent のデプロイには関係ありません。 - -Agent が正常に動作するためには、443/tcp 上の SSL で Datadog サービスにトラフィックを送信する機能が必要です。Agent が使用するポートの全リストは、[ネットワークトラフィック][26]を参照してください。 - -状況によっては、Agent のバージョン固有のエンドポイントがメンテナンスの問題を引き起こすことがありますが、その場合、Datadog はバージョンに依存しないエンドポイントを提供することができます。バージョンに依存しないエンドポイントが必要な場合は、Datadog のサポートにお問い合わせください。 - -#### Agent プロキシ - -多くのクライアント環境では、Agent から Datadog への直接接続を開始することは不可能であるか、または希望されません。接続を可能にするために、Datadog は Agent のトラフィックをプロキシするいくつかの異なるオプションを提供しています。 - -詳しくは、[Agent プロキシの構成][27]をご覧ください。 - -### Agent のデプロイ、アップグレード、構成 - -Datadog Agent を自社やクライアントのインフラストラクチャーにデプロイするには、様々な方法があります。ほとんどのサービスプロバイダーは、すでに構成管理ツールを導入しているため、Agent の展開には既存のツールを使用するのがよいでしょう。 - -Datadog Agent を構成管理ツールで管理する例をご紹介します。 -- [Chef を使用した Datadog Agent のデプロイ][28] (ブログ) -- [Puppet + Datadog: システムの自動化 + 監視][7] (ブログ) -- [CloudFormation を使用した Datadog のデプロイと構成][29] (ブログ) -- [Ansible を使って Datadog の構成を自動化する方法][30] (ビデオ) -- [Ansible のダイナミックインベントリを使って AWS ホストに Datadog Agent をデプロイする方法][31] (ブログ) - -Datadog のリポジトリを使用する予定がない場合は、常に[パブリック GitHub リポジトリ][32]で最新の Agent のリリースを見つけることができます。デプロイ前に Agent パッケージの[ディストリビューションチャンネルを確認][33]することをお勧めします。 - -### 継続的なプロビジョニングプロセスの監視 - -Datadog のデプロイには構成管理ツールを使用することが望ましいですが、Datadog を活用してこれらのツールの適切な運用を監視することも可能です。以下はその例です。 -- [システムに現状を聞く: Datadog を使って Chef を監視する][34] (ブログ) -- [Ansible + Datadog: 自動化を監視し、監視を自動化する][35] (ブログ) - -## 次のステップ - -Datadog にデータが流れ込んだら、次はクライアントに[価値を提供する][36]ことに集中する時です。 - - -[1]: /ja/getting_started/integrations/ -[2]: https://www.datadoghq.com/pdf/monitoring-in-the-cloud-ebook.pdf -[3]: https://www.datadoghq.com/solutions/aws/ -[4]: https://www.datadoghq.com/solutions/gcp/ -[5]: https://www.datadoghq.com/solutions/azure/ -[6]: /ja/integrations/ -[7]: /ja/agent/ -[8]: /ja/getting_started/agent/ -[9]: /ja/getting_started/logs -[10]: /ja/api/latest/metrics -[11]: /ja/api/latest/events -[12]: /ja/api/latest/tracing/ -[13]: /ja/developers/custom_checks/ -[14]: /ja/service_management/events/guides/dogstatsd/ -[15]: /ja/metrics/custom_metrics/ -[16]: /ja/developers/community/libraries/#api-and-dogstatsd-client-libraries -[17]: /ja/api/latest/ -[18]: /ja/getting_started/tagging/ -[19]: https://www.datadoghq.com/blog/tagging-best-practices/ -[20]: https://learn.datadoghq.com/courses/tagging-best-practices -[21]: /ja/getting_started/tagging/unified_service_tagging?tab=kubernetes -[22]: /ja/agent/kubernetes/tag/ -[23]: https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html -[24]: /ja/serverless/serverless_tagging/?tab=serverlessframework#overview -[25]: /ja/infrastructure/livecontainers -[26]: /ja/agent/configuration/network/ -[27]: /ja/agent/configuration/proxy/ -[28]: https://www.datadoghq.com/blog/deploying-datadog-with-chef-roles/ -[29]: https://www.datadoghq.com/blog/monitor-puppet-datadog/ -[30]: https://www.datadoghq.com/blog/deploying-datadog-with-cloudformation/ -[31]: https://www.youtube.com/watch?v=EYoqwiXFrlQ -[32]: https://github.com/DataDog/datadog-agent/releases -[33]: /ja/data_security/agent/#agent-distribution -[34]: https://www.datadoghq.com/blog/monitor-chef-with-datadog/ -[35]: https://www.datadoghq.com/blog/ansible-datadog-monitor-your-automation-automate-your-monitoring/ -[36]: /ja/partners/delivering-value/ \ No newline at end of file From 79a2cb5e619f7af3c4774e97dec648ae8e1999fa Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:57:17 +0100 Subject: [PATCH 25/29] Deleting translations of content/fr/partners/data-intake.md --- content/fr/partners/data-intake.md | 205 ----------------------------- 1 file changed, 205 deletions(-) delete mode 100644 content/fr/partners/data-intake.md diff --git a/content/fr/partners/data-intake.md b/content/fr/partners/data-intake.md deleted file mode 100644 index 5f48d6180f031..0000000000000 --- a/content/fr/partners/data-intake.md +++ /dev/null @@ -1,205 +0,0 @@ ---- -description: Commencez à transmettre vos données à Datadog et découvrez les exigences - que doivent respecter vos environnements et ceux de vos clients. -private: true -title: Ingestion de données ---- - -Maintenant que vous avez tout préparé, il est temps de commencer à transmettre vos données à Datadog. - -L'objectif initial de cette phase est de rassembler suffisamment de données pour générer immédiatement de la valeur ajoutée, aussi bien pour vous que pour vos clients. Ce processus doit toutefois s'inscrire sur le long terme afin de tenir compte en permanence des évolutions de votre environnement. Posez-vous régulièrement les questions suivantes : -- Une nouvelle technologie a-t-elle été déployée dans votre environnement ou celui de vos clients ? -- Un nouveau processus a-t-il été mis en place ? -- La plateforme Datadog propose-t-elle une nouvelle fonctionnalité dont vous pouvez tirer parti ? - -En répondant régulièrement à ces questions, vous vous assurerez que toutes les données de télémétrie nécessaires sont ingérées dans Datadog. - -## Intégrations - -Les intégrations sont idéales pour offrir immédiatement de la valeur ajoutée à vos clients. Datadog propose {{< translate key="integration_count" >}} intégrations qui permettent de recueillir des métriques et des logs depuis un large éventail de technologies. - -Il existe trois grandes catégories d'intégrations : -- Intégrations de services cloud -- Agent Datadog et intégrations basées sur l'Agent -- Intégrations basées sur des API/bibliothèques et checks custom - -Pour en savoir plus sur les différents types d'intégrations, consultez [Présentation des intégrations][1]. - -## Intégrations de services cloud - -Les intégrations basées sur un service cloud ou un « crawler » utilisent une connexion authentifiée pour récupérer des informations sur l'infrastructure, des métriques, des logs et des événements depuis un service cloud via une API. - -La configuration d'une intégration de service cloud ne prend généralement que quelques minutes, et les métriques et événements ingérés par Datadog génèrent immédiatement de la valeur ajoutée. - -**Remarque** : les intégrations de services cloud peuvent générer de vastes quantités de données, ce qui peut affecter votre facture Datadog et celle du fournisseur de cloud. - -Il convient de noter que dans la plupart des cas, l'utilisation d'une intégration de service cloud n'est pas suffisante pour bénéficier d'une visibilité complète sur l'infrastructure et notamment sur les applications qui s'exécutent dans ces environnements. Datadog vous recommande de tirer parti de l'ensemble des méthodes de collecte de données, et pas seulement des intégrations de services cloud. - -Pour en savoir plus sur la surveillance des environnements cloud, consultez les ressources suivantes : -- [Surveillance du cloud][2] (eBook) -- [Présentation de la surveillance du cloud AWS][3] (Blog) -- [Présentation de la surveillance du cloud Google][4] (Blog) -- [Présentation de la surveillance du cloud Azure][3] (Blog) - -## Agent Datadog et intégrations basées sur l'Agent - -L'Agent Datadog est un logiciel qui s'exécute sur vos hosts et recueille des événements et des métriques pour ensuite les envoyer à Datadog. L'Agent est disponible pour toutes les plateformes couramment utilisées. Bien que le logiciel par défaut soit en mesure de recueillir diverses métriques à propos du host sur lequel il est exécuté (notamment des métriques relatives au processeur, à la mémoire, au disque et au réseau), la véritable force de l'Agent réside dans ses intégrations. - -Les intégrations basées sur l'Agent permettent au logiciel de recueillir des métriques, des logs, des traces et des événements à partir des applications et des technologies exécutées soit directement sur le host, soit au sein des conteneurs exécutés sur le host. - -Pour en savoir plus sur les intégrations et l'Agent Datadog, consultez les ressources suivantes : -- [Liste des intégrations Datadog][6] -- [L'Agent Datadog][7] -- [Débuter avec l'Agent][8] - -## Intégrations basées sur des API/bibliothèques et checks custom - -Datadog est une plateforme scalable et évolutive qui offre plusieurs API et SDK pour étendre ses capacités dans les situations où : -- L'Agent ne peut pas être installé en raison de restrictions de sécurité ou autres, par exemple sur les appareils IoT -- L'Agent Datadog ou ses intégrations ne sont pas en mesure de couvrir une technologie ou une exigence spécifique - -Dans ces cas de figure, vous avez la possibilité d'utiliser des API pour capturer les données de télémétrie qui vous intéressent et les transférer vers la plateforme d'observabilité pour vos clients. - -En tant que fournisseur de service, il existe trois catégories d'API susceptibles de vous intéresser : -- API publiques pour l'ingestion de données -- Checks custom -- API locales pour l'ingestion de données sur l'Agent - -### API publiques pour l'ingestion de données - -Lorsqu'il n'est pas possible ou pas souhaitable d'utiliser l'Agent ou les intégrations de service cloud, l'ingestion des données peut être effectuée à l'aide des API suivantes : - -- Les logs peuvent être transmis directement à l'[endpoint d'ingestion des logs][9] de Datadog. -- Les métriques peuvent être transmises directement à l'[API des métriques][10] de Datadog. -- Les événements peuvent être transmis directement à l'[API des événements][11] de Datadog. -- Les traces peuvent être transmises directement à l'[API des traces/spans][10] de Datadog. - -### Checks custom - -Bien que Datadog offre {{< translate key="integration_count" >}} intégrations, il est possible que votre client exécute une application personnalisée qui n'est couverte par aucune des intégrations existantes. Pour surveiller une telle application, votre client peut utiliser l'Agent pour exécuter des checks custom. - -Pour en savoir plus, consultez la section [Checks custom][13]. - -### API locales pour l'ingestion de données sur l'Agent - -L'Agent Datadog est fourni avec DogStatsD, un service d'agrégation de métriques, qui accepte les données via UDP. DogStatsD est une excellente alternative aux checks custom si ces derniers ne répondent pas à vos besoins et qu'il n'existe aucune intégration pour l'application. Par exemple, vous pouvez utiliser DogStatsD pour recueillir des événements et des métriques à partir d'une tâche cron, pour laquelle il n'existe probablement aucun fichier de log. - -Vous pouvez utiliser les endpoints DogStatsD ou tirer parti d'une bibliothèque client Datadog pour envoyer vos métriques et événements via DogStatsD. - -Pour en savoir plus, consultez les ressources suivantes : -- [Envoyer des événements][14] -- [Envoyer des métriques custom][15] -- [Bibliothèques][16] -- [Références sur les API][17] - -## Stratégie de tagging - -Il est essentiel d'adopter une bonne stratégie de tagging pour exploiter tout le potentiel des fonctionnalités de Datadog. - -Les tags sont des étiquettes associées à vos données qui vous permettent de filtrer, regrouper et mettre en corrélation vos données dans Datadog. En appliquant des tags en fonction des différents types de données de télémétrie dans Datadog, vous pourrez mettre en corrélation vos métriques, traces et logs et effectuer des actions sur ces derniers. Diverses clés de tag réservées sont proposées à cette fin. - -Pour tirer le meilleur parti de Datadog et optimiser la valeur ajoutée proposée à vos clients, il convient de mettre en place une bonne stratégie de tagging dès le départ. - -Lorsque vous réfléchissez aux tags à appliquer, assurez-vous de tenir compte des facteurs suivants : -- **Technologie** : permet de comparer l'utilisation d'une même technologie d'une équipe ou d'un client à l'autre. -- **Environnement** : permet de comparer les performances de vos environnements de test, de production, etc. -- **Emplacement** : permet d'analyser les problèmes qui concernent un centre de données ou une zone de disponibilité d'un fournisseur de services cloud spécifique. -- **Service métier** : permet de filtrer les composants clés d'un service métier, quelle que soit la technologie utilisée. -- **Rôle** : permet de comprendre le rôle que joue une entité dans un service métier. -- **Responsabilité** : permet à l'équipe responsable de filtrer ses propres ressources, et permet aux autres utilisateurs d'identifier l'équipe en charge d'un certain service. - -Pour optimiser votre stratégie et mettre tous les chances de votre côté, consultez [Débuter avec les tags][18]. - -Pour en savoir plus sur les tags et la stratégie de tagging, consultez les ressources suivantes : -- [Bonnes pratiques en matière de tagging pour votre infrastructure et vos applications][19] (Blog) -- [Recommandations relatives aux tags][20] (Training) -- [Tagging de service unifié][21] -- [Extraction de tags dans Kubernetes][22] -- [Gérer les tags dans AWS][23] (documentation AWS) -- [Tagging de fonctions sans serveur][24] -- [Tagging de live containers][25] - -## Déploiement de l'Agent - -Voici les phases clés de déploiement de l'Agent : -- Prérequis avant le déploiement de l'Agent -- Déploiement initial de l'Agent dans une infrastructure existante -- Provisionnement d'une nouvelle infrastructure -- Surveillance des processus de provisionnement continu - -### Prérequis avant le déploiement de l'Agent - -Les prérequis à respecter pour l'Agent dépendent de la plateforme et du système d'exploitation utilisés. Consultez la [documentation officielle de l'Agent][7] pour prendre connaissance de ces exigences. - -Quelle que soit la plateforme utilisée, le principal prérequis pour utiliser l'Agent est la présence d'une connectivité réseau. Le trafic est toujours généré par l'Agent et envoyé vers Datadog. Aucune session n'est jamais initiée par Datadog vers l'Agent. Sauf dans de rares cas, la connectivité entrante (limitée par les pare-feu locaux) n'est pas un élément à prendre en compte pour le déploiement de l'Agent. - -Pour fonctionner correctement, l'Agent doit pouvoir envoyer du trafic au service Datadog via SSL sur le port 443/tcp. Pour connaître la liste complète des ports utilisés par l'Agent, consultez [Trafic réseau][26]. - -Il arrive que certains endpoints propres à une version spécifique de l'Agent entraînent des problèmes de maintenance ; dans ce cas, Datadog peut mettre à disposition un endpoint compatible avec n'importe quelle version. Si vous avez besoin d'un tel endpoint, contactez l'assistance Datadog. - -#### Utiliser un proxy pour l'Agent - -Il est souvent impossible ou déconseillé d'ouvrir une connexion directe entre l'Agent et Datadog. Pour assurer la connectivité entre les deux, Datadog propose différents moyens de faire passer le trafic de l'Agent par un proxy. - -Pour en savoir plus, consultez [Configuration de l'Agent pour un proxy][27]. - -### Déploiement, mise à jour et configuration de l'Agent - -Il existe plusieurs façons de déployer l'Agent Datadog sur votre infrastructure et celle de votre client. Étant donné que la plupart des fournisseurs de services proposent déjà un outil de gestion des configurations, il est recommandé d'utiliser cet outil pour déployer l'Agent. - -Voici quelques exemples de guides pour gérer votre Agent Datadog avec différents outils de gestion des configurations : -- [Déployer des Agents Datadog avec Chef][28] (Blog) -- [Puppet + Datadog : Automatisez et surveillez vos systèmes][7] (Blog) -- [Déployer et configurer Datadog avec CloudFormation][29] (Blog) -- [Comment utiliser Ansible pour automatiser la configuration de Datadog][30] (Vidéo) -- [Comment déployer l'Agent Datadog sur des hosts AWS avec les inventaires dynamiques Ansible][31] (Blog) - -Si vous ne comptez pas utiliser les référentiels de Datadog, sachez que les dernières versions de l'Agent sont disponibles en permanence sur le [référentiel GitHub public][32]. Nous vous conseillons de [vérifier le canal de distribution][33] des packages de l'Agent avant de procéder à son déploiement. - -### Surveillance des processus de provisionnement continu - -S'il est conseillé d'utiliser des outils de gestion des configurations pour déployer Datadog, vous pouvez également utiliser Datadog pour contrôler le bon fonctionnement de ces outils. Voici quelques exemples : -- [Demandez à vos systèmes ce qui se passe : surveiller Chef avec Datadog][34] (Blog) -- [Ansible + Datadog : surveillez votre automatisation, automatisez votre surveillance][35] (Blog) - -## Et ensuite ? - -Maintenant que vos données sont ingérées par Datadog, il est temps de [générer de la valeur ajoutée][36] pour vos clients. - - -[1]: /fr/getting_started/integrations/ -[2]: https://www.datadoghq.com/pdf/monitoring-in-the-cloud-ebook.pdf -[3]: https://www.datadoghq.com/solutions/aws/ -[4]: https://www.datadoghq.com/solutions/gcp/ -[5]: https://www.datadoghq.com/solutions/azure/ -[6]: /fr/integrations/ -[7]: /fr/agent/ -[8]: /fr/getting_started/agent/ -[9]: /fr/getting_started/logs -[10]: /fr/api/latest/metrics -[11]: /fr/api/latest/events -[12]: /fr/api/latest/tracing/ -[13]: /fr/developers/custom_checks/ -[14]: /fr/events/guides/dogstatsd/ -[15]: /fr/metrics/custom_metrics/ -[16]: /fr/developers/community/libraries/#api-and-dogstatsd-client-libraries -[17]: /fr/api/latest/ -[18]: /fr/getting_started/tagging/ -[19]: https://www.datadoghq.com/blog/tagging-best-practices/ -[20]: https://learn.datadoghq.com/courses/tagging-best-practices -[21]: /fr/getting_started/tagging/unified_service_tagging?tab=kubernetes -[22]: /fr/agent/kubernetes/tag/ -[23]: https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html -[24]: /fr/serverless/serverless_tagging/?tab=serverlessframework#overview -[25]: /fr/infrastructure/livecontainers -[26]: /fr/agent/guide/network/ -[27]: /fr/agent/proxy/ -[28]: https://www.datadoghq.com/blog/deploying-datadog-with-chef-roles/ -[29]: https://www.datadoghq.com/blog/monitor-puppet-datadog/ -[30]: https://www.datadoghq.com/blog/deploying-datadog-with-cloudformation/ -[31]: https://www.youtube.com/watch?v=EYoqwiXFrlQ -[32]: https://github.com/DataDog/datadog-agent/releases -[33]: /fr/data_security/agent/#agent-distribution -[34]: https://www.datadoghq.com/blog/monitor-chef-with-datadog/ -[35]: https://www.datadoghq.com/blog/ansible-datadog-monitor-your-automation-automate-your-monitoring/ -[36]: /fr/partners/delivering-value/ \ No newline at end of file From d142cb15446d3253d6e025a6cb8112dbc6816c64 Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:57:31 +0100 Subject: [PATCH 26/29] Deleting translations of content/es/partners/data-intake.md --- content/es/partners/data-intake.md | 207 ----------------------------- 1 file changed, 207 deletions(-) delete mode 100644 content/es/partners/data-intake.md diff --git a/content/es/partners/data-intake.md b/content/es/partners/data-intake.md deleted file mode 100644 index 3b346a856b525..0000000000000 --- a/content/es/partners/data-intake.md +++ /dev/null @@ -1,207 +0,0 @@ ---- -description: Introducción de datos en Datadog y requisitos previos que debe cumplir - tu entorno o el de tus clientes. -private: true -title: Introducción de datos ---- - -Ya has sentado las bases y es hora de empezar a introducir datos en Datadog. - -Inicialmente, el objetivo de esta fase debe ser recopilar datos que te aporten valor inmediato a ti o a tus clientes. Pero, a largo plazo, debes considerarla un proceso continuo en el que evalúas constantemente los cambios en tu entorno haciéndote las siguientes preguntas: -- ¿Tú o tus clientes han empleado una nueva tecnología? -- ¿Tú o tus clientes han introducido un nuevo proceso? -- ¿Ha introducido Datadog una nueva función de producto que puedas utilizar? - -Considera estas preguntas con frecuencia para asegurarte de que toda la telemetría necesaria se está ingiriendo en Datadog. - -## Integraciones - -Puedes proporcionar valor inmediato a tus clientes a través de las integraciones. Datadog ofrece integraciones {{< translate key="integration_count" >}}, que recopilan métricas y logs de una amplia gama de tecnologías. - -Existen tres categorías principales de integraciones: -- Integraciones de servicios en la nube -- Integraciones del Datadog Agent y basadas en el Agent -- Integraciones de API / biblioteca y checks personalizados - -Para obtener más información sobre los distintos tipos de integraciones, consulta [Introducción a integraciones][1]. - -## Integraciones de servicios en la nube - -Las integraciones basadas en servicios o "crawlers" utilizan una conexión autenticada para recopilar información, métricas, logs y eventos de infraestructura de un servicio en la nube utilizando una API. - -Configurar una integración de servicios en la nube suele llevar sólo unos minutos y aporta un valor inmediato con métricas y eventos que fluyen a Datadog. - -**Nota**: Las integraciones de servicios en la nube pueden generar grandes volúmenes de datos que pueden tener efectos en la facturación tanto de Datadog como del proveedor de la nube. - -Ten en cuenta que, en la mayoría de los escenarios, el uso de una integración de servicios en la nube no será suficiente para obtener una comprensión completa de la infraestructura y, especialmente, de las aplicaciones que se ejecutan en estos entornos. Datadog recomienda aprovechar todos los medios de recopilación de datos, además de las integraciones de servicios en la nube. - -Para saber más sobre la monitorización de entornos de nube, consulta: -- [Monitorización en la nube][2] (eBook) -- [Introducción a la monitorización AWS Cloud][3] (Blog) -- [Introducción a la monitorización Google Cloud][4] (Blog) -- [Introducción a la monitorización Azure Cloud][5] (Blog) - -## Integraciones del Datadog Agent y basadas en el Agent - -El Datadog Agent es un software que se ejecuta en hosts y recopila eventos y métricas para enviarlos a Datadog. El Agent está disponible para todas las plataformas de uso común. Aunque el propio Agent puede recopilar una serie de métricas sobre el host en el que se ejecuta (como métricas de CPU, memoria, disco y red), el verdadero punto fuerte del Agent son sus integraciones. - -Las integraciones basadas en el Agent permiten al Agent recopilar métricas, logs, trazas (traces) -y eventos de aplicaciones y tecnologías que se ejecutan directamente en -el host o en contenedores que se ejecutan en el host. - -Para obtener más información sobre integraciones y el Datadog Agent, consulta: -- [Lista de integraciones Datadog][6] -- [Datadog Agent][7] -- [Empezando con el Agent][8] - -## Integraciones de API / biblioteca y checks personalizados - -Datadog se centra en la escalabilidad y la extensibilidad y ofrece varias API y SDK para ampliar la plataforma en situaciones en las que: -- La instalación del Agent podría no ser posible debido a restricciones de seguridad o de otro tipo, por ejemplo en dispositivos IoT. -- Las capacidades del Datadog Agent y su integraciones no cubren una tecnología o requisito. - -En estos casos, el uso de la API te permite capturar telemetría relevante en la plataforma de observabilidad para tus clientes. - -Como proveedor de servicio, hay tres áreas clave de API que podrían interesarte más: -- API públicas para la ingestión de datos -- Checks personalizados -- API locales para la ingestión de datos en el Agent - -### API públicas para la ingestión de datos - -En los casos en que el uso de integraciones de servicios en la nube o del Agent no sea posible o deseado, las siguientes API pueden ser útiles para la ingesta de datos: - -- Los logs pueden reenviarse directamente al [endpoint de ingestión de logs][9] de Datadog. -- Las métricas pueden reenviarse directamente a la [API de métricas][10] de Datadog. -- Los eventos pueden reenviarse directamente a la [API de eventos][11] de Datadog. -- Las trazas pueden reenviarse directamente a la [API de rastreo/tramo (span)][12] de Datadog. - -### Checks personalizados - -Aunque Datadog ofrece integraciones {{< translate key="integration_count" >}}, es posible que tu cliente ejecute una aplicación personalizada que no pueda ser cubierta por ninguna de las integraciones existentes. Para monitorizar estas aplicaciones, tus clientes pueden utilizar el Agent para ejecutar checks personalizados. - -Para obtener más información, consulta [Checks personalizados][13]. - -### API locales para la ingestión de datos en el Agent - -El Datadog Agent viene con DogStatsD, un servicio de agregación de métricas que acepta datos utilizando UDP. DogStatsD es una buena alternativa si un check personalizado no se adapta a tu caso de uso, y no existen integraciones para la aplicación. Por ejemplo, puedes utilizar DogStatsD para recopilar datos de eventos y métricas de un trabajo cron que probablemente no tenga sus propios archivos de logs. - -Puedes utilizar los endpoints de DogStatsD o una biblioteca cliente de Datadog para facilitar el envío de métricas y eventos a DogStatsD. - -Para obtener más información, consulta: -- [Enviar eventos][14] -- [Enviar métricas personalizadas][15] -- [Bibliotecas][16] -- [Referencia API][17] - -## Estrategia de etiquetado - -Una buena estrategia de etiquetado es esencial si quieres asegurarte de que tanto tú como tus clientes puedan beneficiarse de todas las funciones de Datadog. - -Las etiquetas (tags) son etiquetas (labels) adjuntas a los datos que permiten filtrar, agrupar y correlacionar datos en Datadog. El etiquetado vincula diferentes tipos de telemetría en Datadog, lo que permite la correlación y las llamadas a la acción entre métricas, trazas y logs. Esto se consigue con las claves de etiquetado reservadas. - -Definir una estrategia coherente de etiquetado por adelantado allana el camino para una implementación satisfactoria de Datadog y, en última instancia, aumenta la obtención de valor para tus clientes. - -Cuando pienses en el etiquetado, ten en cuenta los siguientes factores: -- **Tecnología**: Te permite comparar el uso de una misma tecnología entre equipos o clientes. -- **Entorno**: Te permite comparar el rendimiento entre entornos de test, producción y otros entornos. -- **Localización**: Te permite comprender los problemas relacionados con centros de datos específicos o zonas de disponibilidad de proveedores de servicio en la nube. -- **Servicio empresarial**: Te permite a ti y a tus clientes filtrar los componentes básicos de un servicio empresarial, independientemente de la tecnología. -- **Rol**: Te permite comprender qué rol desempeña una entidad en un servicio empresarial. -- **Responsabilidad**: Permite al equipo responsable filtrar todos sus recursos y permite a otros usuarios y equipos identificar qué equipo es responsable de un determinado servicio. - -Para prepararte para el éxito, lee [Empezando con etiquetas (tags)][18]. - -Para obtener más información sobre el etiquetado y la estrategia de etiquetado, consulta: -- [Prácticas recomendadas para el etiquetado de tu infraestructura y tus aplicaciones][19] (Blog) -- [Prácticas recomendadas para el etiquetado][20] (Capacitación) -- [Etiquetado unificado de servicios][21] -- [Extracción de etiquetas (tags) de Kubernetes][22] -- [Etiquetado AWS][23] (Documentación de AWS) -- [Etiquetado serverless][24] -- [Etiquetado de contenedores en directo][25] - -## Implementación del Agent - -Estas son las fases clave de implementación del Agent: -- Requisitos previos para la implementación del Agent -- Despliegue inicial del Agent en la infraestructura existente -- Suministro de una nueva infraestructura -- Monitorización de procesos de suministro continuo - -### Requisitos previos para el despliegue del Agent - -Dependiendo de la plataforma y del sistema operativo, puede haber diferentes requisitos previos del Agent. Para familiarizarte con estos requisitos, consulta [la documentación oficial del Agent][7]. - -El principal requisito previo del Agent en cualquier plataforma es la conectividad de red. El tráfico siempre se inicia desde el Agent hacia Datadog. Nunca se inician sesiones desde Datadog hacia el Agent. Salvo en casos excepcionales, la conectividad entrante (limitada a través de cortafuegos locales) no es un factor a tener en cuenta en los despliegues del Agent. - -Para funcionar correctamente, el Agent requiere la capacidad de enviar tráfico al servicio Datadog mediante SSL a través de 443/tcp. Para ver una lista completa de los puertos utilizados por el Agent, consulta [Tráfico de red][26]. - -En algunas circunstancias, los endpoints específicos de la versión del Agent pueden causar problemas de mantenimiento, en cuyo caso Datadog puede proporcionar un endpoint independiente de la versión. Si necesitas un endpoint independiente de la versión, ponte en contacto con el servicio de asistencia de Datadog. - -#### Proxy del Agent - -En muchos entornos de clientes, abrir una conectividad directa desde el Agent a Datadog no es posible o deseado. Para habilitar la conectividad, Datadog ofrece algunas opciones diferentes para actuar como intermediarios en el tráfico del Agent. - -Para obtener más información, consulta la [configuración del proxy del Agent][27]. - -### Despliegue, actualización y configuración del Agent - -Existen varias formas de desplegar el Datadog Agent en tu propia infraestructura y en la de tus clientes. Como la mayoría de los proveedores de servicios ya disponen de una herramienta de gestión de la configuración, se recomienda utilizar la herramienta existente para el despliegue del Agent. - -He aquí algunos ejemplos de cómo gestionar tu Datadog Agent con las herramientas de gestión de la configuración: -- [Despliegue del Datadog Agent con Chef][28] (Blog) -- [Puppet + Datadog: Automatizar + Monitorizar tus sistemas][7] (Blog) -- [Despliegue y configuración de Datadog con CloudFormation][29] (Blog) -- [Uso de Ansible para automatizar la configuración de Datadog][30] (Vídeo) -- [Despliegue del Datadog Agent en hosts AWS con inventarios dinámicos de Ansible][31] (Blog) - -Si no tienes previsto utilizar los repositorios de Datadog, siempre puedes encontrar las últimas versiones del Agent en el [repositorio público de GitHub][32]. Se recomienda [verificar el canal de distribución][33] de los paquetes del Agent antes del despliegue. - -### Monitorización de procesos de suministro continuo - -Aunque es una práctica recomendada utilizar herramientas de gestión de la configuración para desplegar Datadog, también puedes aprovechar Datadog para monitorizar el funcionamiento adecuado de estas herramientas. He aquí algunos ejemplos: -- [Pregunta a tus sistemas qué está pasando: Monitorizar Chef con Datadog][34] (Blog) -- [Ansible + Datadog: Monitorizar tu automatización, automatizar tu monitorización][35] (Blog) - -## ¿Qué es lo que sigue? - -Ahora que los datos fluyen hacia Datadog, es el momento de centrarte en [ofrecer valor][36] a tus clientes. - - -[1]: /es/getting_started/integrations/ -[2]: https://www.datadoghq.com/pdf/monitoring-in-the-cloud-ebook.pdf -[3]: https://www.datadoghq.com/solutions/aws/ -[4]: https://www.datadoghq.com/solutions/gcp/ -[5]: https://www.datadoghq.com/solutions/azure/ -[6]: /es/integrations/ -[7]: /es/agent/ -[8]: /es/getting_started/agent/ -[9]: /es/getting_started/logs -[10]: /es/api/latest/metrics -[11]: /es/api/latest/events -[12]: /es/api/latest/tracing/ -[13]: /es/developers/custom_checks/ -[14]: /es/service_management/events/guides/dogstatsd/ -[15]: /es/metrics/custom_metrics/ -[16]: /es/developers/community/libraries/#api-and-dogstatsd-client-libraries -[17]: /es/api/latest/ -[18]: /es/getting_started/tagging/ -[19]: https://www.datadoghq.com/blog/tagging-best-practices/ -[20]: https://learn.datadoghq.com/courses/tagging-best-practices -[21]: /es/getting_started/tagging/unified_service_tagging?tab=kubernetes -[22]: /es/agent/kubernetes/tag/ -[23]: https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html -[24]: /es/serverless/serverless_tagging/?tab=serverlessframework#overview -[25]: /es/infrastructure/livecontainers -[26]: /es/agent/configuration/network/ -[27]: /es/agent/configuration/proxy/ -[28]: https://www.datadoghq.com/blog/deploying-datadog-with-chef-roles/ -[29]: https://www.datadoghq.com/blog/monitor-puppet-datadog/ -[30]: https://www.datadoghq.com/blog/deploying-datadog-with-cloudformation/ -[31]: https://www.youtube.com/watch?v=EYoqwiXFrlQ -[32]: https://github.com/DataDog/datadog-agent/releases -[33]: /es/data_security/agent/#agent-distribution -[34]: https://www.datadoghq.com/blog/monitor-chef-with-datadog/ -[35]: https://www.datadoghq.com/blog/ansible-datadog-monitor-your-automation-automate-your-monitoring/ -[36]: /es/partners/delivering-value/ \ No newline at end of file From f784b69bc059a08f91d310eccb12f0a7d299a72a Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:57:44 +0100 Subject: [PATCH 27/29] Deleting translations of content/ko/partners/data-intake.md --- content/ko/partners/data-intake.md | 206 ----------------------------- 1 file changed, 206 deletions(-) delete mode 100644 content/ko/partners/data-intake.md diff --git a/content/ko/partners/data-intake.md b/content/ko/partners/data-intake.md deleted file mode 100644 index c2b87c7aa8cb0..0000000000000 --- a/content/ko/partners/data-intake.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -description: Datadog로 데이터를 피드하는 방법과 사용자나 클라이언트 환경에 있어야 할 필수 구성 요소를 알아봅니다. -private: true -title: 데이터 수집 ---- - -기초 작업을 마쳤으면 이제 Datadog로 데이터를 받아야 합니다. - -이 단계의 주 목적은 사용자나 클라이언트에게 바로 가치를 제공할 수 있도록 데이터를 모으는 것입니다. 그러나 장기적으로 다음과 같은 질문을 통해 지속적으로 환경 변화를 평가하는 상시 프로세스로 이 단계를 봐야 합니다. -- 사용자 또는 클라이언트가 새 기술을 도입했나요? -- 사용자 또는 클라이언트가 새 프로세스를 도입했나요? -- Datadog에서 사용자가 사용할 수 있는 새 제품을 출시했나요? - -이 같은 질문을 정기적으로 해보고 필요한 텔레메트리가 모두 Datadog로 수집되는지 확인하세요. - -## 통합 - -통합을 이용해 클라이언트에게 바로 가치를 제공할 수 있습니다. Datadog에서는 {{< translate key="integration_count" >}}개의 통합 서비스를 제공하기 때문에 폭넓은 기술에서 메트릭과 로그를 수집할 수 있습니다. - -통합에는 다음과 같은 세 가지 카테고리가 있습니다. -- 클라우드 서비스 통합 -- Datadog 에이전트 및 에이전트 기반 통합 -- API/라이브러리 통합 및 커스텀 점검 - -다른 통합 유형에 관한 자세한 정보는 [통합 소개][1]를 참고하세요. - -## 클라우드 서비스 통합 - -클라우드 서비스나 "크롤러' 기반 통합은 인증된 연결을 통해 API를 이용하여 클라우드 서비스에서 인프라스트럭처 정보, 메트릭, 로그, 이벤트를 수집합니다. - -클라우드 서비스 통합을 설정하는 시간은 몇 분 정도면 충분하며, 메트릭과 이벤트가 Datadog로 전송되어 바로 가치 제공에 활용할 수 있습니다. - -**참고**: 클라우드 서비스 통합을 이용하면 대량으로 데이터가 생성될 수 있고, 이는 Datadog와 클라우드 서비스 청구 요금에 영향을 미칠 수 있습니다. - -대부분의 시나리오에서 클라우드 서비스 통합을 사용하더라도 인프라스트럭처 전체를 이해하는 데는 부족할 수 있고, 특히 이와 같은 환경에서 실행 중인 애플리케이션을 이해하는 데는 더욱 그러합니다. Datadog에서는 클라우드 서비스 통합과 함께 다른 데이터 수집 방법을 모두 활용하기를 권장합니다. - -클라우드 환경 모니터링에 대해 알아보려면 다음을 참고하세요. -- [클라우드 모니트링][2](전자책) -- [AWS 클라우드 모니터링 소개][3](블로그) -- [Google 클라우드 모니터링 소개][4](블로그) -- [Azure 클라우드 모니터링 소개][5](블로그) - -## Datadog 에이전트 및 에이전트 기반 통합 - -Datadog 에이전트는 호스트에서 실행되는 소프트웨어로, 이벤트와 메트릭을 수집해 Datadog로 전송합니다. 에이전트는 일반적으로 사용하는 플랫폼에서 모두 사용할 수 있고, 실행 중인 호스트에 관한 다양한 메트릭(CPU, 메모리, 디스크, 네트워크 메트릭 등)을 수집할 수 있습니다. 그러나 에이전트의 강점은 통합에서 발휘됩니다. - -에이전트 기반 통합을 사용하면 에이전트를 통해 애플리케이션 및 호스트나 -호스트 내 컨테이너에서 직접 실행 중인 기술에서 에이전트가 메트릭, 로그, 트레이스, -이벤트를 수집할 수 있습니다. - -통합 및 Datadog 에이전트와 관련한 자세한 정보는 다음을 참고하세요. -- [Datadog 통합 목록][6] -- [Datadog 에이전트][7] -- [에이전트 시작하기][8] - -## API/라이브러리 통합 및 커스텀 점검 - -Datadog에서는 규모와 기능 확장성에 초점을 두고 여러 API와 SDK를 제공해 다음과 같은 상황에서도 플랫폼을 확장할 수 있도록 합니다. -- 보안이나 기타 제한으로 인해 에이전트를 설치할 수 없는 경우(예: IoT 디바이스). -- Datadog 에이전트와 통합이 사용 중인 기술과 요구 사항을 충족하지 않을 경우. - -이와 같은 경우, API를 사용하면 관련 텔레메트리를 클라이언트가 사용하는 가시성 플랫폼으로 캡처해 보낼 수 있습니다. - -서비스 공급자로서 중요하게 볼 API 영역에는 세 개가 있습니다. -- 데이터 수집용 공용 API -- 커스텀 점검 -- 에이전트의 데이터 수집용 로컬 API - -### 데이터 수집용 공용 API - -클라우드 서비스 통합이나 에이전트를 사용할 수 없을 경우, 데이터 수집을 위해 다음 API를 유용하게 사용할 수 있습니다. - -- 로그를 Datadog의 [로그 수집 엔드포인트][9]로 바로 전송할 수 있음. -- 메트릭을 Datadog의 [메트릭 API][10]로 바로 전송할 수 있음. -- 이벤트를 Datadog의 [이벤트 API][1]로 바로 전송할 수 있음. -- 트레이스를 Datadog의 [트리이스/스팬 API][12]로 바로 전송할 수 있음. - -### 커스텀 점검 - -Datadog에서 {{< translate key="integration_count" >}}개의 통합 서비스를 제공하고 있지만, 클라이언트가 커스텀 애플리케이션을 사용 중이라면 기존 통합을 사용하지 못할 수 있습니다. 클라이언트가 에이전트를 사용해 커스텀 점검을 하면 이 같은 애플리케이션을 모니터링할 수 있습니다. - -자세한 정보는 [커스텀 점검][13]을 참고하세요. - -### 에이전트의 데이터 수집용 로컬 API - -Datadog 에이전트 번들에는 DogStatsD가 포함되어 있는데, DogStatsD는 메트릭 집계 서비스로 UDP를 사용해 데이터를 수용합니다. 커스텀 점검이 내 사용 사례에 맞지 않고 애플리케이션에 사용할 기존 통합도 없는 경우, DogStatsD가 좋은 대안이 될 수 있습니다. 예를 들어 DogStatsD를 사용해 자체 로그 파일이 없는 크론(cron) 작업에서 이벤트와 메트릭 데이터를 수집할 수 있습니다. - -DogStatsD 엔드포인트를 사용하거나 Datadog 클라이언트 라이브러리를 사용해 메트릭과 이벤트를 DogStatsD로 전송할 수 있습니다. - -자세한 정보는 다음을 참고하세요. -- [이벤트 제출][14] -- [커스텀 메트릭 제출][15] -- [라이브러리][16] -- [API 레퍼런스][17] - -## 태깅 전략 - -Datadog 기능을 최대한을 활용하려면 태깅 전략을 효과적으로 사용해야 합니다. - -태그는 데이터에 연결된 레이블로, Datadog 전반에서 데이터를 필터링 및 그룹화하고 상관 관계를 정의하는 데 사용됩니다. 태깅을 통해 Datadog 내 여러 텔레메트리 유형을 한 데 묶고, 메트릭, 트레이스, 로그 간 상관 관계를 발견하고 작업을 요청할 수 있습니다. 예약된 태그 키로 이 같은 작업을 실행할 수 있습니다. - -초반에 일관된 태깅 전략을 수립하면 성공적으로 Datadog를 구현할 수 있을 뿐만 아니라 클라이언트에게 제공할 수 있는 가치도 최대화할 수 있습니다. - -태깅에 대해서는 다음 사항을 고려하세요. -- **기술**: 팀이나 클라이언트 간 같은 기술을 사용하고 있는지 비교할 수 있습니다. -- **환경**: 테스트, 프로덕션, 기타 환경 간 성능을 비교할 수 있습니다. -- **위치**: 특정 데이터 센터나 클라우드 서비스 공급자 가용 영역과 관련한 문제를 이해할 수 있습니다. -- **비즈니스 서비스**: 기술과 무관하게 비즈니스 서비스의 구성 요소를 필터링할 수 있습니다. -- **역할**: 비즈니스 서비스에서 엔터티가 어떤 역할을 수행하는지 이해할 수 있습니다. -- **책임**: 담당 팀의 리소스 모두를 필터링할 수 있어 다른 사용자와 팀이 특정 서비스에 대해 책임이 있는 팀을 확인할 수 있습니다. - -태그를 효율적으로 활용하려면 [태그 시작하기][18]를 참고하세요. - -태깅과 태깅 전략에 관한 자세한 정보는 다음을 참고하세요. -- [인프라스트럭처 및 애플리케이션 태깅 모범 사례][19](블로그) -- [태깅 모범 사례][20](교육) -- [통합 서비스 태깅][21] -- [쿠버네티스 태그 추출][22] -- [AWS 태깅][23](AWS 설명서) -- [서버리스 태깅][24] -- [라이브 컨테이너 태깅][25] - -## 에이전트 출시 - -다음은 에이전트 출시와 관련한 핵심 단계입니다. -- 에이전트 배포 사전 필수 조건 -- 기존 인프라스트럭처로 첫 에이전트 배포 -- 새 인프라스트럭처 프로비저닝 -- 연속 프로비저닝 절차 모니터링 - -### 에이전트 배포 사전 필수 조건 - -플랫폼과 운영 체제에 따라 에이전트 사전 필수 조건이 다를 수 있습니다. [공식 에이전트 설명서][7]를 참고해 요구 조건을 미리 알아두세요. - -플랫폼 전체에서 공통적으로 필요한 조건은 네트워크 연결입니다. 트래픽은 항상 에이전트에서 시작해 Datadog로 흐릅니다. Datadog에서 시작해 에이전트로 가는 세션은 없습니다. 몇몇 예외를 제외하고, 에이전트 배포에 인바운드 연결(로컬 방화벽을 통해 제한됨)은 중요하지 않습니다. - -에이전트가 올바로 작동하려면 트래픽을 SSL 및 443/tcp를 통해 Datadog 서비스로 전송해야 합니다. 에이전트에서 사용하는 포트 전체 목록을 보려면 [네트워크 트래픽][26]을 참고하세요. - -일부 환경에서 특정 에이전트 버전의 엔드포인트가 유지보수 문제를 일으킬 수 있는데, 이 경우 Datadog에서 버전에 영향을 받지 않는 엔드포인트를 제공할 수 있습니다. 버전에 영향을 받지 않는 엔드포인트가 필요한 경우 Datadog 지원팀에 문의하세요. - -#### 에이전트 프록시 - -클라이언트 환경 대다수의 경우, 에이전트에서 Datadog로 직접 연결을 형성하는 것이 불가능하거나 좋은 방법이 아닐 수 있습니다. Datadog에서는 연결을 형성할 때 사용할 수 있는 다양한 에이전트 트래픽 프록시 옵션을 제공합니다. - -자세한 정보는 [에이전트 프록시 구성][27]을 참고하세요. - -### 에이전트 배포, 업그레이드, 구현 - -Datadog 에이전트를 사용자나 클라이언트 인프라스트럭처로 배포하는 데는 다양한 방법이 있습니다. 서비스 공급자 대부분이 이미 자체 구성 관리 도구를 갖추고 있기 때문에 에이전트의 경우에도 기존 도구를 사용하는 것이 좋습니다. - -다음은 구성 관리 도구를 사용해 Datadog 에이전트를 관리하는 예시이니 참고하세요. -- [Chef로 Datadog 에이전트 배포하기][28](블로그) -- [Puppet + Datadog: 자동 + 시스템 모니터링하기][7](블로그) -- [CloudFormation으로 Datadog 배포 및 구현하기][29](블로그) -- [Ansible을 사용해 Datadog 자동 구성하기][30](비디오) -- [Ansible 동적 인벤토리가 있는 AWS 호스트에서 Datadog 에이전트를 배포하는 방법][31](블로그) - -Datadog 리포지토리를 사용하지 않을 계획이라면 [공용 GitHub 리포지토리][32]에서 최신 에이전트 릴리즈를 찾을 수 있습니다. 배포하기 전에 에이전트 패키지의 [분포 채널을 인증][33]하는 것이 좋습니다. - -### 연속 프로비저닝 절차 모니터링 - -Datadog를 배포할 때 구성 관리 도구를 사용하는 것이 좋으며, Datadog를 활용해 이 같은 도구가 제대로 작동하는지도 모니터링할 수 있습니다. 다음 예시를 참고하세요. -- [시스템 문제 알아보기: Datadog로 Chef 모니터링][34](블로그) -- [Ansible + Datadog: 자동화를 모니터링, 모니터링을 자동화][35](블로그) - -## 다음 단계 - -Datadog로 데이터가 들어오기 시작하면 클라이언트에게 [가치를 제공][36]하는 것에 집중할 수 있습니다. - - -[1]: /ko/getting_started/integrations/ -[2]: https://www.datadoghq.com/pdf/monitoring-in-the-cloud-ebook.pdf -[3]: https://www.datadoghq.com/solutions/aws/ -[4]: https://www.datadoghq.com/solutions/gcp/ -[5]: https://www.datadoghq.com/solutions/azure/ -[6]: /ko/integrations/ -[7]: /ko/agent/ -[8]: /ko/getting_started/agent/ -[9]: /ko/getting_started/logs -[10]: /ko/api/latest/metrics -[11]: /ko/api/latest/events -[12]: /ko/api/latest/tracing/ -[13]: /ko/developers/custom_checks/ -[14]: /ko/service_management/events/guides/dogstatsd/ -[15]: /ko/metrics/custom_metrics/ -[16]: /ko/developers/community/libraries/#api-and-dogstatsd-client-libraries -[17]: /ko/api/latest/ -[18]: /ko/getting_started/tagging/ -[19]: https://www.datadoghq.com/blog/tagging-best-practices/ -[20]: https://learn.datadoghq.com/courses/tagging-best-practices -[21]: /ko/getting_started/tagging/unified_service_tagging?tab=kubernetes -[22]: /ko/agent/kubernetes/tag/ -[23]: https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html -[24]: /ko/serverless/serverless_tagging/?tab=serverlessframework#overview -[25]: /ko/infrastructure/livecontainers -[26]: /ko/agent/configuration/network/ -[27]: /ko/agent/configuration/proxy/ -[28]: https://www.datadoghq.com/blog/deploying-datadog-with-chef-roles/ -[29]: https://www.datadoghq.com/blog/monitor-puppet-datadog/ -[30]: https://www.datadoghq.com/blog/deploying-datadog-with-cloudformation/ -[31]: https://www.youtube.com/watch?v=EYoqwiXFrlQ -[32]: https://github.com/DataDog/datadog-agent/releases -[33]: /ko/data_security/agent/#agent-distribution -[34]: https://www.datadoghq.com/blog/monitor-chef-with-datadog/ -[35]: https://www.datadoghq.com/blog/ansible-datadog-monitor-your-automation-automate-your-monitoring/ -[36]: /ko/partners/delivering-value/ \ No newline at end of file From 30bffca8bce9458f387a81f264e8b73fc1708c0e Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:58:00 +0100 Subject: [PATCH 28/29] Deleting translations of content/ja/partners/laying-the-groundwork.md --- content/ja/partners/laying-the-groundwork.md | 179 ------------------- 1 file changed, 179 deletions(-) delete mode 100644 content/ja/partners/laying-the-groundwork.md diff --git a/content/ja/partners/laying-the-groundwork.md b/content/ja/partners/laying-the-groundwork.md deleted file mode 100644 index d22af3f4cbf57..0000000000000 --- a/content/ja/partners/laying-the-groundwork.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -description: どのように始めればよいのか、また、最初の段階でどのような重要な決定をすればよいのか。 -private: true -title: 基礎固め ---- - -このパートでは、Datadog マネージドサービスプロバイダーとしての旅の最初の段階で行うべき重要な決定事項について説明します。 - -## マネージドサービスプロバイダーが考慮すべき主な事項 - -サービスプロバイダーとして Datadog を使い始める方法は、ビジネスモデルや運用モデルによって異なります。 - -- **ビジネスモデル**: クライアントが Datadog にアクセスできるようにするかどうかが、重要なポイントになります。クライアントに Datadog へのアクセスを提供する場合、複数組織のアカウントを設定し、クライアントデータを分離して非公開にします。 -- **運用モデル**: もう 1 つの重要な考慮点は、クライアントベースが多くの同種のクライアントで構成されており、見た目が似ている多くの Datadog 組織のプログラム管理がより重要であるか、またはクライアントの数が少ないか、異種であるかということです。 - -以上を踏まえて、Datadog による MSP のセットアップの基礎が整ったことになります。 - -## 前提条件 - -サービスプロバイダーとして Datadog の導入に取り組む前に、DPN ポータルで [Datadog テクニカルスペシャリストトレーニング][16]を修了しておくことをお勧めします。 - -トレーニングや認定資格の取得により、次の章で取り上げる多くのトピックに慣れ、すぐに始めることができるようになります。 - -## 組織の設定 - -サービスプロバイダーが行うべき重要な決定の 1 つは、「組織」と呼ばれるクライアントの Datadog アカウントをどのように設定するかということです。ユーザーは複数の組織に関連付けることができますが、監視されるリソースは 1 つの組織に結びつきます。最初から正しい組織構造を選択することで、自社とクライアントの価値を迅速に創出することができます。 - -### 単一組織または複数組織 - -Datadog は、1 つの親組織から複数の子組織を管理することが可能です。これは、クライアントが互いのデータにアクセスできないようにするために、MSP が使用する典型的なデプロイモデルです。複数組織の設定では、各クライアントのために 1 つの子組織が作成され、クライアントは自分の子組織にのみアクセスできます。詳しくは、[クライアントの組織のプロビジョニングオプション](#client-org-provisioning-options)を参照してください。 - -クライアントに Datadog へのアクセスを提供する予定がなく、クライアントデータを分離するための厳格な要件がない場合は、単一組織設定を使用します。 - -組織管理の詳細については、[複数組織アカウントの管理][1]のドキュメントを参照してください。 - -### 開発、テスト、本番で組織を分ける？ - -MSP パートナーからのよくある質問は、開発、テスト、本番環境のリソースを管理するために、Datadog の組織を別々に設定する必要があるかというものです。 - -Datadog では、開発、テスト、本番のリソースを分けることは推奨していません。推奨されるアプローチは、全てのリソースを同じ Datadog 組織で管理し、タグで環境を区切ることです。詳細については、[タグ付け戦略][20]を参照してください。 - -## クライアントの組織のプロビジョニングオプション - -クライアントの Datadog 組織を管理している場合、組織のプロビジョニングプロセスを制御し、新規ユーザーのプロビジョニング、アクセス方法の設定、ロールベースのアクセス定義、クライアントの使用管理など、組織内の管理機能を実行したいと思うかもしれません。 - -そのためには、以下の作業を行います。 - -1. [親アカウントの下に子組織を作成する。](#create-a-child-organization-under-your-parent-account) -2. [新しい子組織の組織 ID を取得する。](#retrieve-the-new-client-orgs-org-id) -3. [新しい子組織を親アカウントから切り離す。](#separate-the-new-child-organization-from-your-parent-account) -4. [新しいクライアントの情報を DPN ポータルに登録する。](#register-the-new-client-details-in-the-dpn-portal) -5. [上のステップ 1 で作成した組織の下に子組織を作成する。](#create-a-new-child-organization-under-the-organization-created-in-step-1-above) - -結果は以下のようになります。 - -- 新しい親組織が、新しいクライアントの 1 つまたは複数の子組織を管理する目的で作成されます。 -- 新しい親組織とクライアントの子組織が登録され、請求契約に添付されます。 -- 新規ユーザーのプロビジョニング、アクセス方法の構成、ロールベースのアクセス定義、新しいクライアント子組織の使用管理が可能になります。 - -### 親アカウントの下に子組織を作成する - -このステップには 2 つのオプションがあります。 - -- UI を使用する: [複数組織アカウントの管理][1]で説明されているように、[New Organization]をクリックします。 -- APIを使用する: [子組織を作成][18]するためのエンドポイントを使用します。 - -### 新しいクライアント組織の組織 ID を取得する - -ブラウザの JavaScript コンソールを開き、次のように入力すれば、ログインしている Datadog 組織の ID を取得できますす。 - -```javascript -JSON.parse(document.querySelector('#_current_user_json').value).org.id -``` - -また、次の JavaScript 関数 を含む `Get Datadog OrgId` という名前のブックマークを作成することもできます。 - -```javascript -javascript:(function() {var orgId = JSON.parse(document.querySelector('#_current_user_json').value).org.id; alert("Datadog OrgId is " + orgId);})(); -``` - -これで、Datadog のページにいるときにブックマークをクリックすると、ブラウザのアラートボックスに現在の組織 ID が表示されます。 - -### 新しい子組織を親アカウントから切り離す - -このステップには 2 つのオプションがあります。 - - セルフサービス: [子組織のスピンオフ][19]のための API エンドポイントを使用して、新しい組織を単独の親組織にする。 - - サポートを依頼する: パートナーセールスマネージャーに連絡して、親アカウントから新組織を切り離してもらいます。 - -### 新しいクライアントの情報を DPN ポータルに登録する - -- [DPN ポータル][16]にログインし、商談ダッシュボードの `+Register Deal` をクリックします。 - -- 新しいクライアントの情報 (組織 ID など) を入力して、新しいクライアント組織を登録します。 - -### 上のステップ 1 で作成した組織の下に新しい子組織を作成する - -1. [上のステップ 1](#create-a-child-organization-under-your-parent-account) で作成した組織に切り替えます。 -2. [上のステップ 1](#create-a-child-organization-under-your-parent-account) の指示に従って、クライアントの子組織を作成します。 - -## カスタムサブドメイン - -多数の組織を扱う際に Datadog の使用感を向上させるには、カスタムサブドメイン機能を使用します。 - -デフォルトでは、どの Datadog 組織も Datadog のアクセスページ、[https://app.datadoghq.com][2] と [https://app.datadoghq.eu][3] からアクセスされるようになっています。ただし、カスタムサブドメインを使用することで、各サブ組織に一意の URL を付与することができます (例: `https://account-a.datadoghq.com`)。 - -詳しくは、[カスタムサブドメイン][4]をご覧ください。 - -## ユーザーロールとカスタムロールベースアクセスコントロール (RBAC) - -経験上、MSP 内部のユーザーとクライアントのユーザーの両方は、しばしば 3 つの [Datadog のデフォルトロール][5]のいずれかに明確に分類されないことがあります。特定の分野でユーザー権限を制限するには、カスタムロールを作成するのが望ましいです。 - -詳しくは、こちらをご覧ください。 - -- [カスタムロール][6] -- [ロールベースアクセスコントロール][7] - -## シングルサインオン (SSO) に関する考慮点 - -サービスプロバイダーのコンテキストでは、シングルサインオン (SSO) について 2 つの考慮事項があります。 - -- 組織のためのシングルサインオン -- クライアントのためのシングルサインオン - -統一された認証メカニズムという明白な利点のほかに、SAML シングルサインオンを使用すると、ユーザのプロビジョニングプロセスが大幅に簡略化されます。SAML を使用すると、ジャストインタイム (JiT) ユーザープロビジョニングを使用できるため、手動またはプログラムによるユーザ作成が不要になります。 - -SAML 認証は、Datadog の組織またはサブ組織で有効になります。つまり、サブ組織ごとに異なる SAML プロバイダーを持つことができるのです。しかし、これは、異なる SAML プロバイダーを持つユーザーの 2 つのグループがある場合、それらのユーザーは別々の組織にいなければならないことも意味します。複数組織の設定を計画する際には、SAML 認証について考えておくようにしましょう。 - -詳しくは、こちらをご覧ください。 - -- 複数組織アカウントに [SAML を設定する][8] -- [SAML によるシングルサインオン][9] - -## ユーザーの管理 - -### ユーザーの作成 - -Datadog は、各組織のユーザーを迅速にプロビジョニングするための複数の方法を提供しています。 - -- [UI によるユーザーの一括追加][10] -- [API によるユーザー作成][11] -- SAML のような認証サービスと[ジャストインタイム (JiT) プロビジョニング][12]を併用する - -### ユーザートレーニング - -Datadog の目標は、簡単で直感的に使えるサービスを提供することです。経験上、ほとんどのユーザーが快適に製品を操作し、学びながら進めています。 - -ここでは、製品の最も重要な点に関するトレーニングを希望するユーザーにとって有用なリソースを紹介します。 - -- [Datadog の YouTube チャンネル][13]: Datadog の YouTube チャンネルでは、新機能がリリースされるたびに紹介ビデオが投稿され、ヒントとコツやベストプラクティスに関するビデオもあり、ハイレベルなトレーニングに最適なソースとなっています。 -- [Datadog ラーニングセンター][14]: Datadog ラーニングセンターは、ユーザーがプラットフォームを深く知るための素晴らしい方法です。ラーニングセンターに登録すると、Datadog のサンドボックス環境が自動的に無料でプロビジョニングされ、ユーザーは何かを壊す心配なく製品を使いこなすことができるようになります。 -- [Datadog ブログ][15]: 700 以上のエントリーがあるこのブログは、クライアント環境における主要なサービス、ツール、テクノロジーを監視するための Datadog の使い方や、最新の製品リリースに関する情報を提供する重要な情報源となっています。 -- [Datadog Partner Network (DPN) Enablement Center][16]: DPN を通じて、Datadog のパートナーは、サービスプロバイダーの営業担当者や技術専門家向けの一連のビデオコースにアクセスすることができます。 - -クライアント向けに独自のトレーニング教材を作成する予定がある場合や、どのようなコンテンツが有用かについて推奨がある場合は、Datadog パートナーの担当者にお問い合わせください。 - -## 次のステップ - -次のパート、[データの取り込み][17]では、Datadog にデータを送り込むことに焦点を当てます。 - -[1]: /ja/account_management/multi_organization/ -[2]: https://app.datadoghq.com -[3]: https://app.datadoghq.eu -[4]: /ja/account_management/multi_organization/#custom-sub-domains -[5]: /ja/account_management/rbac/?tab=datadogapplication#datadog-default-roles -[6]: /ja/account_management/rbac/?tab=datadogapplication#custom-roles -[7]: /ja/account_management/rbac/ -[8]: /ja/account_management/multi_organization/#set-up-saml -[9]: /ja/account_management/saml/ -[10]: /ja/account_management/users/#add-new-members-and-manage-invites -[11]: /ja/api/latest/users/#create-a-user -[12]: /ja/account_management/saml/#just-in-time-jit-provisioning -[13]: https://www.youtube.com/user/DatadogHQ -[14]: https://learn.datadoghq.com/ -[15]: https://www.datadoghq.com/blog/ -[16]: https://partners.datadoghq.com/ -[17]: /ja/partners/data-intake/ -[18]: /ja/api/latest/organizations/#create-a-child-organization -[19]: /ja/api/latest/organizations/#spin-off-child-organization -[20]: /ja/partners/data-intake/#tagging-strategy \ No newline at end of file From 3945bef20816411c4d1c58777b423c59908040bb Mon Sep 17 00:00:00 2001 From: guacbot Date: Mon, 12 May 2025 20:58:14 +0100 Subject: [PATCH 29/29] Deleting translations of content/fr/partners/laying-the-groundwork.md --- content/fr/partners/laying-the-groundwork.md | 113 ------------------- 1 file changed, 113 deletions(-) delete mode 100644 content/fr/partners/laying-the-groundwork.md diff --git a/content/fr/partners/laying-the-groundwork.md b/content/fr/partners/laying-the-groundwork.md deleted file mode 100644 index 4d2462b338865..0000000000000 --- a/content/fr/partners/laying-the-groundwork.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -description: Découvrez comment vous lancer ainsi que les décisions clés à prendre - dès le début. -private: true -title: Préparation du terrain ---- - -Cette partie du guide aborde les décisions clés que vous devez prendre au début de votre parcours en tant que prestataire de services gérés Datadog. - -## Considérations clés pour les prestataires de services gérés - -La meilleure façon de se lancer en tant que prestataire de services Datadog dépend de votre modèle commercial et de votre modèle opérationnel : -- **Modèle commercial** : Vous devez impérativement déterminer si vous souhaitez donner à vos clients un accès direct à Datadog ou non. Si vous choisissez de laisser vos clients accéder à Datadog, configurez un compte multi-organisations pour que les données de chaque client restent séparées et privées. -- **Modèle opérationnel** : Demandez-vous également si votre clientèle est constituée de nombreux clients homogènes, auquel cas la gestion automatique de nombreuses organisations Datadog de même nature sera l'aspect le plus important, ou si vous travaillez avec des clients plus restreints ou plus hétérogènes. -Après avoir répondu aux questions ci-dessus, vous pouvez procéder à la configuration de Datadog en tant que prestataire de services gérés. -## Prérequis - -Avant d'implémenter Datadog en tant que prestataire de services, nous vous conseillons de suivre la formation Technical Specialist de Datadog. - -La formation et la certification vous aideront à vous familiariser avec un grand nombre des sujets abordés dans les chapitres suivants, et vous pourrez ainsi vous lancer sans attendre. - -## Configuration de l'organisation - -En tant que prestataire de services, vous devez d'abord déterminer comment vous souhaitez configurer les comptes Datadog de vos clients, également appelés « organisations ». Si un utilisateur peut être associé à plusieurs organisations, ce n'est pas le cas des ressources surveillées, qui sont propres à chaque organisation. En choisissant la structure qui vous convient le mieux dès le départ, vous pourrez générer de la valeur ajoutée plus rapidement pour vous et vos clients. - -### Organisation unique ou compte multi-organisations - -Datadog offre la possibilité de gérer plusieurs organisations enfant à partir d'une seule organisation parent. Ce modèle de déploiement est généralement privilégié par les prestataires de services gérés, car il permet d'empêcher que les clients aient accès aux données des autres. Dans une structure multi-organisations, une organisation enfant est créée pour chaque client, et le client a uniquement accès à sa propre organisation enfant. - -Optez pour une organisation unique si vous ne comptez pas donner à vos clients accès à Datadog et que vous n'avez pas besoin de séparer les données de chaque client. - -Pour en savoir plus sur la gestion des organisations, consultez la section [Gestion des comptes multi-organisations][1]. - -### Faut-il utiliser des organisations séparées pour les environnements de développement, de test et de production ? - -Les prestataires de services se demandent souvent s'il est préférable de configurer des organisations Datadog distinctes pour gérer les ressources de développement, de test et de production au sein de leurs environnements. - -Datadog vous déconseille de séparer vos ressources de développement, de test et de production. La méthode recommandée est de gérer toutes vos ressources depuis la même organisation Datadog et d'utiliser des tags pour faire la distinction entre vos différents environnements. Pour en savoir plus, consultez la section [Stratégie de tagging](#strategie-de-tagging). - -## Sous-domaines personnalisés - -Si vous gérez un vaste nombre d'organisations, utilisez la fonctionnalité de sous-domaines personnalisés pour améliorer votre expérience Datadog. - -Par défaut, l'accès aux différentes organisations Datadog se fait via les pages [https://app.datadoghq.com][2] et [https://app.datadoghq.eu][3]. Toutefois, vous pouvez configurer des sous-domaines personnalisés afin de définir une URL unique pour chaque sous-organisation. Exemple : `https://compte-a.datadoghq.com`. - -Pour en savoir plus, consultez la section [Sous-domaines personnalisés][4]. - -## Rôles utilisateur et contrôle d'accès à base de rôles (RBAC) - -L'expérience a montré que les utilisateurs internes au prestataire de services et les utilisateurs des différents clients ne correspondent pas toujours clairement à l'un des trois [rôles par défaut de Datadog][5]. Il est conseillé de créer des rôles personnalisés pour limiter l'accès des utilisateurs aux sections qui les concernent. - -Pour en savoir plus, consultez les ressources suivantes : -- [Rôles personnalisés][6] -- [Contrôle d'accès à base de rôles (RBAC)][7] - -## Considérations relatives à l'authentification unique (SSO) - -En tant que prestataire de services, il existe deux aspects de l'authentification unique (SSO) à prendre compte : -- Authentification unique pour votre organisation -- Authentification unique pour vos clients - -Outre les avantages évidents d'un mécanisme d'authentification unifié, l'utilisation de l'authentification unique SAML simplifie considérablement le processus de provisionnement d'utilisateurs. SAML vous permet d'utiliser le provisionnement juste à temps (JiT) des utilisateurs, éliminant ainsi le besoin de créer des utilisateurs manuellement ou via un système automatisé. - -L'authentification SAML peut être est activée au niveau de chaque organisation ou sous-organisation Datadog, ce qui signifie que vous pouvez configurer des fournisseurs SAML différents pour chaque sous-organisation. Sachez toutefois que si vous avez deux groupes d'utilisateurs avec des fournisseurs SAML différents, ces utilisateurs devront faire partie d'organisations distinctes. Assurez-vous de prendre en compte l'authentification SAML durant la planification de votre structure multi-organisations. - -Pour en savoir plus, consultez les ressources suivantes : -- [Configurer SAML][8] pour les comptes multi-organisations -- [Authentification unique avec SAML][9] - -## Gestion des utilisateurs - -### Création des utilisateurs - -Datadog offre plusieurs façons de provisionner rapidement des utilisateurs pour leurs organisations respectives : - -- [Ajouter des groupes d'utilisateurs depuis l'interface][10] -- [Créer des utilisateurs via l'API][11] -- Utiliser un service d'authentification comme SAML avec le [provisionnement juste à temps (JiT)][12] - -### Formation des utilisateurs - -L'objectif de Datadog est de proposer un service intuitif et simple d'utilisation. L'expérience a montré que la plupart des utilisateurs apprécient découvrir le produit par eux-mêmes au fur et à mesure. - -Si toutefois certains utilisateurs préfèrent se former sur les aspects essentiels du produit, voici quelques ressources utiles : - -- [Chaîne YouTube de Datadog][13] : La chaîne propose des vidéos de présentation des nouvelles fonctionnalités, des conseils et astuces ainsi que des recommandations. Il s'agit d'un excellent moyen de découvrir le fonctionnement général du produit. -- [Centre d'apprentissage de Datadog][14] : Le centre d'apprentissage Datadog est idéal pour se familiariser avec la plateforme en profondeur. Lorsqu'un utilisateur rejoint le centre d'apprentissage, un environnement sandbox Datadog est automatiquement et gratuitement mis à sa disposition, lui permettant ainsi d'expérimenter avec le produit sans crainte de casser quoi que ce soit. -- [Blog de Datadog][15] : Avec plus de 700 articles publiés, le blog est une source d'informations essentielle pour découvrir comment surveiller les services, outils et technologies clés qui composent les environnements de vos clients avec Datadog, ainsi que pour rester au courant des nouveaux produits proposés. -- [Portail du réseau de partenaires Datadog][16] : Le portail permet aux prestataires de services qui travaillent en partenariat avec Datadog d'accéder à des formations vidéo à destination du personnel commercial et technique. - -Contactez votre représentant Datadog si vous envisagez de créer vos propres supports de formation pour vos clients et que vous souhaitez recommander du contenu à ajouter. - -## Et ensuite ? - -La partie suivante du guide, [Ingestion de données][17], s'intéresse à l'envoi de données à Datadog. - -[1]: /fr/account_management/multi_organization/ -[2]: https://app.datadoghq.com -[3]: https://app.datadoghq.eu -[4]: /fr/account_management/multi_organization/#custom-sub-domains -[5]: /fr/account_management/rbac/?tab=datadogapplication#datadog-default-roles -[6]: /fr/account_management/rbac/?tab=datadogapplication#custom-roles -[7]: /fr/account_management/rbac/ -[8]: /fr/account_management/multi_organization/#set-up-saml -[9]: /fr/account_management/saml/ -[10]: /fr/account_management/users/#add-new-members-and-manage-invites -[11]: /fr/api/latest/users/#create-a-user -[12]: /fr/account_management/saml/#just-in-time-jit-provisioning -[13]: https://www.youtube.com/user/DatadogHQ -[14]: https://learn.datadoghq.com/ -[15]: https://www.datadoghq.com/blog/ -[16]: https://partners.datadoghq.com/ -[17]: /fr/partners/data-intake/ \ No newline at end of file