diff --git a/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx b/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx
index f4d1b72800e..73e7a10d848 100644
--- a/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx
+++ b/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx
@@ -413,21 +413,18 @@ For setting up alerts related to data ingest limits and query limits, see [Set a
To see changes made to your account (for example, changes related to managing users), you can query [`NrAuditEvent`](/docs/insights/insights-data-sources/default-data/nrauditevent-event-data-query-examples).
-## Usage-related data types [#data-types]
+## Usage-related events and attributes [#data-types]
For an advanced deep dive into managing data ingest in a complex organization, see [Data ingest governance](/docs/new-relic-solutions/observability-maturity/operational-efficiency/dg-intro/).
-Usage data is attached to the following events. For more detail on which event to use for querying users, see [Query users](#user-queries).
+These are the primary events to query for understanding your usage:
-* `NrUsage` records usage every hour and is used to see the types of data being reported (for example, data or browser monitoring data).
* `NrConsumption` records usage every hour, and is the equivalent of "real-time" usage. Use this event to observe usage trends over time.
* `NrMTDConsumption` generates aggregate values from the `NrConsumption` event. Use this event to see usage by monthly billing period. This is the best event for querying user count.
-## Data ingest attributes [#data-ingest-attributes]
-
-Below are some of the most important attributes attached to usage-related events.
+Here are some of the most important attributes attached to usage-related events.
diff --git a/src/content/docs/licenses/license-information/usage-plans/new-relic-usage-plan.mdx b/src/content/docs/licenses/license-information/usage-plans/new-relic-usage-plan.mdx
index 3760a653164..9ba8193ec8d 100644
--- a/src/content/docs/licenses/license-information/usage-plans/new-relic-usage-plan.mdx
+++ b/src/content/docs/licenses/license-information/usage-plans/new-relic-usage-plan.mdx
@@ -29,7 +29,7 @@ Undefined terms used in this Usage Plan or Order shall have the meaning set fort
title="Pay As You Go, or PAYG"
>
* Customer commits to paying for the New Relic Products on a consumption basis. A PAYG Order has a rolling one-day term ("Commitment Term").
- * Customer's usage of the Products in excess of the [Free Tier](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing) each month shall be billed in arrears on the first business day of the following month based on the Customer's Per Unit usage of each Product each month multiplied by the corresponding rates set forth in an Order or this Usage Plan and summed (“Monthly Product Usage”).
+ * Customer's usage of the Products in excess of the [Free Edition](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing) each month shall be billed in arrears on the first business day of the following month based on the Customer's Per Unit usage of each Product each month multiplied by the corresponding rates set forth in an Order or this Usage Plan and summed (“Monthly Product Usage”).
* Customer may request termination of its PAYG Buying Programs at any time with written notice to New Relic at billing@newrelic.com with fees being payable up until the effective date of such termination.
@@ -516,7 +516,7 @@ Details:
If you're on the Pay As You Go buying program, then your usage of the Products is covered by the [Paid Terms of Service](https://newrelic.com/termsandconditions/paid) for any paid months. Otherwise, unpaid months usage of the Products are covered by the [Unpaid Terms of Service](https://newrelic.com/termsandconditions/unpaid).
diff --git a/src/content/docs/new-relic-solutions/observability-maturity/operational-efficiency/data-governance-baseline-ingest-guide.mdx b/src/content/docs/new-relic-solutions/observability-maturity/operational-efficiency/data-governance-baseline-ingest-guide.mdx
index 6b7e21ee73d..065c29861c3 100644
--- a/src/content/docs/new-relic-solutions/observability-maturity/operational-efficiency/data-governance-baseline-ingest-guide.mdx
+++ b/src/content/docs/new-relic-solutions/observability-maturity/operational-efficiency/data-governance-baseline-ingest-guide.mdx
@@ -317,7 +317,7 @@ In a [pay-as-you-go plan](/docs/accounts/accounts-billing/new-relic-one-pricing-
Not sure of your data cost? See [Ingested data](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-prices).
-### Free tier [#free-tier]
+### Free edition [#free-tier]
With all [our editions](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing#editions), you get 100GB data ingest per month for free. For details on data ingest prices above the free amount, see [the list price table](/docs/licenses/license-information/usage-plans/new-relic-usage-plan/#list-price).
diff --git a/src/content/docs/release-notes/agent-release-notes/java-release-notes/java-agent-860.mdx b/src/content/docs/release-notes/agent-release-notes/java-release-notes/java-agent-860.mdx
index 8a16542c0e0..6c1816b4991 100644
--- a/src/content/docs/release-notes/agent-release-notes/java-release-notes/java-agent-860.mdx
+++ b/src/content/docs/release-notes/agent-release-notes/java-release-notes/java-agent-860.mdx
@@ -3,7 +3,7 @@ subject: Java agent
releaseDate: '2023-09-07'
version: 8.6.0
downloadLink: 'https://download.newrelic.com/newrelic/java-agent/newrelic-agent/8.6.0/'
-features: ["Support latest Wildfly", "Support JBoss EAP 7.4", "Support Spring Cache", "Support GraphQL 19.7+", "Support Spring Cache", "Kafka client node metrics", "Kafka client config events", "Improved Struts 2 instrumentation", "Improved code-level metrics for Servlets"]
+features: ["Support latest Wildfly", "Support JBoss EAP 7.4", "Support Spring Cache", "Support Spring Cache", "Kafka client node metrics", "Kafka client config events", "Improved Struts 2 instrumentation", "Improved code-level metrics for Servlets"]
bugs: ["Fixed a bug in the Spring instrumentation when OpenFeign was used.", "Fixed a bug where utility classes were not weaved.",
"Fixed a bug where the agent would not properly send its dependencies."]
security: []
@@ -23,8 +23,6 @@ security: []
- Support latest JBoss EAP [#1336](https://github.com/newrelic/newrelic-java-agent/issues/1336)
-- Support GraphQL 19.7+ [#1469](https://github.com/newrelic/newrelic-java-agent/pull/1469)
-
- Spring Cache instrumentation [#1458](https://github.com/newrelic/newrelic-java-agent/issues/1458)
This new instrumentation module allows you to see how your caches are performing. It provides hit/miss metrics as well as clear and evict.
diff --git a/src/content/docs/style-guide/word-choice/pricing-language-guidelines.mdx b/src/content/docs/style-guide/word-choice/pricing-language-guidelines.mdx
index 03ccb3488f9..12f67e350e9 100644
--- a/src/content/docs/style-guide/word-choice/pricing-language-guidelines.mdx
+++ b/src/content/docs/style-guide/word-choice/pricing-language-guidelines.mdx
@@ -44,7 +44,7 @@ Some notes on style and formatting for pricing-related language:
* When referencing a model, it's good practice to point to either the doc for that model, or else the [doc explaining the differences between the models](/docs/accounts/original-accounts-billing/original-product-based-pricing/overview-changes-pricing-user-model/#pricing-user-table), whichever makes more sense.
* "usage-based." Our newer pricing model can be referred to as “usage-based” or “consumption-based,” but “usage-based” is the most commonly used and more preferred term.
* Editions:
- * Our [pricing editions](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing/#editions) are not "plans" or "models" or "tiers"; they are "editions". One exception is that it's acceptable to refer to the Free edition as the "free tier" simply because we have used that label in the past.
+ * Our [pricing editions](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing/#editions) are not "plans" or "models" or "tiers"; they are "editions." One exception is that it's acceptable to refer to the Free edition as the "free tier" simply because we have used that in the past.
* Our pricing editions are formatted with title case: Free, Standard, Pro, and Enterprise. Example use: _If your organization is on the [Pro edition](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing/#editions)..._
* A New Relic organization can have only a single edition.
* Avoid referring to users by their edition (e.g., _your Pro users_ or _Enterprise users_). The cost of billable users does differ depending on edition, but we should attempt to keep these two dimensions separate. Example wording: _an organization with Pro edition and 10 full platform users_.
diff --git a/src/content/docs/synthetics/synthetic-monitoring/getting-started/monitor-limits.mdx b/src/content/docs/synthetics/synthetic-monitoring/getting-started/monitor-limits.mdx
index 94a4bf064a3..740edc60251 100644
--- a/src/content/docs/synthetics/synthetic-monitoring/getting-started/monitor-limits.mdx
+++ b/src/content/docs/synthetics/synthetic-monitoring/getting-started/monitor-limits.mdx
@@ -21,10 +21,10 @@ Your [pricing edition](/docs/accounts/accounts-billing/new-relic-one-pricing-bil
The following are the synthetic checks included for free on each pricing edition:
-* Free tier: 500 per month
-* Standard edition: 10K per month
-* Pro edition: 1M per month
-* Enterprise edition: 10M per month
+* Free: 500 per month
+* Standard: 10K per month
+* Pro: 1M per month
+* Enterprise: 10M per month
## Exceeding free amount [#exceeding-free]
diff --git a/src/content/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration.mdx b/src/content/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration.mdx
index 89c33718293..0d7722d57ba 100644
--- a/src/content/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration.mdx
+++ b/src/content/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration.mdx
@@ -1,7 +1,7 @@
---
title: Synthetics job manager configuration
tags:
- - Synthetics
+ - synthetics
- Synthetic monitoring
- Private locations
metaDescription: Customize your New Relic synthetics job manager.
@@ -217,7 +217,7 @@ Environmental variables allow you to fine-tune the synthetics job manager config
- **REQUIRED if `synthetics.privateLocationKeySecretName` is not set**. [Private location key](/docs/synthetics/synthetic-monitoring/private-locations/install-job-manager/#private-location-key) of the private location, as found on the private location web page.
+ **REQUIRED if `synthetics.privateLocationKeySecretName` is not set**. [Private location key](/docs/synthetics/synthetic-monitoring/private-locations/install-job-manager/#private-location-key) of the private location, as found on the private location web page.
@@ -252,7 +252,7 @@ Environmental variables allow you to fine-tune the synthetics job manager config
The name of the secret object used to pull an image from a specified container registry.
-
+
`fullnameOverride`
@@ -262,7 +262,7 @@ Environmental variables allow you to fine-tune the synthetics job manager config
Name override used for your Deployment, replacing the default.
-
+
`appVersionOverride`
@@ -405,7 +405,7 @@ Environmental variables allow you to fine-tune the synthetics job manager config
Set a custom security context for the synthetics-job-manager pod.
-
+
`ping-runtime.enabled`
@@ -441,7 +441,7 @@ Environmental variables allow you to fine-tune the synthetics job manager config
Default: `docker.io/newrelic/synthetics-ping-runtime`
-
+
`ping-runtime.image.pullPolicy`
@@ -501,7 +501,7 @@ Environmental variables allow you to fine-tune the synthetics job manager config
Default: `docker.io/newrelic/synthetics-node-api-runtime`
-
+
`node-api-runtime.image.pullPolicy`
@@ -562,7 +562,7 @@ Environmental variables allow you to fine-tune the synthetics job manager config
Default: `docker.io/newrelic/synthetics-node-browser-runtime`
-
+
`node-browser-runtime.image.pullPolicy`
@@ -595,29 +595,28 @@ If you're working in larger environments, you may need to customize the job mana
In addition to the sizing configuration settings listed below, additional synthetics job managers can be deployed with the same private location key to load balance jobs across multiple environments.
-
-
-Each runtime used by the K8s synthetic job manager can be sized independently by setting values in the [helm chart](https://github.com/newrelic/helm-charts/tree/master/charts/synthetics-job-manager).
+## Kubernetes [#k8s]
-Additional ping runtimes can be started to help execute ping monitor load by increasing the `ping-runtime.replicaCount` setting from the default value of `1`.
+Each runtime used by the Kubernetes synthetic job manager can be sized independently by setting values in the [helm chart](https://github.com/newrelic/helm-charts/tree/master/charts/synthetics-job-manager).
-The Node.js API and Node.js Browser runtimes are sized independently using a combination of the `parallelism` and `completions` settings. Ideal configurations for these settings will vary based on customer requirements.
+Additional ping runtimes can be started to help execute ping monitor load by increasing the `ping-runtime.replicaCount` setting from the default value of `1`.
-The `parallelism` setting controls how many jobs of that type (Node.js API or Node.js Browser) can run concurrently in your K8s cluster. The `parallelism` setting is the equivalent of the `synthetics.heavyWorkers` configuration in the containerized private minion (CPM). Ensure that your K8s cluster has enough resources available to run this number of concurrent runtimes based on their [resource request and limit values](/docs/synthetics/synthetic-monitoring/private-locations/install-job-manager/#kubernetes-requirements).
+The Node.js API and Node.js Browser runtimes are sized independently using a combination of the `parallelism` and `completions` settings. Ideal configurations for these settings will vary based on customer requirements.
-The `completions` setting controls how many jobs of this type must complete before waiting on the every 1 minute `CronJob` schedule to start additional jobs of this runtime type. The `completions` setting should be set to an estimate of how many jobs can be completed in one minute, taking the `parallelism` setting into account. When `completions` is greater than 1, completed jobs will display in `kubectl get pods` but resources are released as soon as those jobs are marked complete or failed.
+The `parallelism` setting controls how many pods of a particular runtime run concurrently. The `parallelism` setting is the equivalent of the `synthetics.heavyWorkers` configuration in the containerized private minion (CPM). Ensure that your Kubernetes cluster has enough resources available to run this number of pods based on their [resource request and limit values](/docs/synthetics/synthetic-monitoring/private-locations/install-job-manager/#kubernetes-requirements).
-Formulae to help calculate a baseline for `completions` and `parallelism` for each runtime:
+The `completions` setting controls how many pods of a particular runtime must complete before the `CronJob` can start another Kubernetes Job for that runtime. Note the difference between a Kubernetes Job (capital J) versus a synthetics monitor job. For improved efficiency, `completions` should be set to 6-10x the `parallelism` value. This can help to minimize the "nearing the end of completions" inefficiency where fewer than the `parallelism` number pods could end up running as the Kubernetes Job waits for all `completions` to finish.
+
+When `completions` is greater than 1, pods with a "Completed" status will remain visible in the output of `kubectl get pods -n YOUR_NAMESPACE` until all completions defined in the Kubernetes Job have been met, for example 6/6 completions. Resources are released from the node when a pod has a status of Completed or Failed.
+
+A Kubernetes Job age of 5 minutes (`kubectl get jobs -n YOUR_NAMESPACE`) is a conservative target to account for variability in how long it takes pods to complete and how many synthetics jobs need to run per minute (jobs rate). The following equations can be used as a starting point for `completions` and `parallelism` for each runtime. Adjustments may need to be made based on observations of private location queue growth.
```m
-completions = 60 / avg job duration
-parallelism = jobs per minute / completions
+completions = 300 / avg job duration (s)
+parallelism = synthetics jobs per minute / completions
```
-Different runtimes will likely have different job durations and rates. The following queries can be used to obtain average duration and rate for a private location.
+Different runtimes will likely have different synthetics job durations and rates. The following queries can be used to obtain average duration and rate for a private location.
```sql
# non-ping average job duration by runtime type
@@ -628,7 +627,7 @@ FROM SyntheticCheck SELECT rate(uniqueCount(id), 1 minute) AS 'jobs per minute'
```
- The above queries are based on current results. If your private location does not have any results or the job manager is not performing at its best, query results may not be accurate. In that case, try a few different values for `completions` and `parallelism` until you see jobs filling at least 1 minute with completions (enough completions) and the queue is not growing (enough parallelism).
+ The above queries are based on current results. If your private location does not have any results or the job manager is not performing at its best, query results may not be accurate. In that case, try a few different values for `completions` and `parallelism` until you see a `kubectl get jobs -n YOUR_NAMESPACE` duration of at least 5 minutes (enough completions) and the queue is not growing (enough parallelism).
@@ -647,46 +646,51 @@ FROM SyntheticCheck SELECT rate(uniqueCount(id), 1 minute) AS 'jobs per minute'
- The runtime will execute 1 job per minute. After 1 job completes, the `CronJob` configuration will start a new job at the next minute. **Throughput will be extremely limited with this configuration.**
+ The runtime will execute 1 synthetics job per minute. After 1 job completes, the `CronJob` configuration will start a new job at the next minute. **Throughput will be extremely limited with this configuration.**
- The runtime will execute 1 job at a time. After the job completes, a new job will start immediately. After the `completions` setting number of jobs completes, the `CronJob` configuration will start a new job and reset the completions counter. **Throughput will be limited, but slightly better.** A single long running job will block the processing of any other jobs of this type.
+ The runtime will execute 1 synthetics job at a time. After the job completes, a new job will start immediately. After the `completions` setting number of jobs completes, the `CronJob` configuration will start a new Kubernetes Job and reset the completions counter. **Throughput will be limited, but slightly better.** A single long running synthetics job will block the processing of any other synthetics jobs of this type.
- The runtime will execute 3 jobs at once. After any of these jobs complete, a new job will start immediately. After the `completions` setting number of jobs completes, the `CronJob` configuration will start a new job and reset the completions counter. **Throughput is much better with this or similar configurations.** A single long running job will have limited impact to the processing of other jobs of this type.
+ The runtime will execute 3 synthetics jobs at once. After any of these jobs complete, a new job will start immediately. After the `completions` setting number of jobs completes, the `CronJob` configuration will start a new Kubernetes Job and reset the completions counter. **Throughput is much better with this or similar configurations.** A single long running synthetics job will have limited impact to the processing of other synthetics jobs of this type.
-If jobs take longer to complete, fewer completions are needed to fill 1 minute but more parallel pods are needed. Similarly, if more jobs need to be processed per minute, more parallel pods are needed.
+If synthetics jobs take longer to complete, fewer completions are needed to fill 5 minutes with jobs but more parallel pods will be needed. Similarly, if more synthetics jobs need to be processed per minute, more parallel pods will be needed. The `parallelism` setting directly affects how many synthetics jobs per minute can be run. Too small a value and the queue may grow. Too large a value and nodes may become resource constrained.
-You can use the `completions` value to obtain a good starting point for the value of `parallelism`. The `parallelism` setting directly affects how many jobs per minute can be run. Too small a value and the queue may grow. Too large a value and the node may become resource constrained.
-
-If your `parallelism` settings is working well to keep the queue at zero, it's not a bad idea to set a higher value for `completions` than what was initially calculated from `60 / avg job duration`. This can help to accommodate cases where jobs complete faster than expected and avoid the scenario where the `completions` value is reached before 1 minute has elapsed. The most efficient `completions` setting will fill the entire minute with running and completing jobs. If not enough completions, job processing for that runtime will sit idle for some number of seconds until the next `CronJob` can spin up another set of `completions`.
-
-
+If your `parallelism` settings is working well to keep the queue at zero, setting a higher value for `completions` than what is calculated from `300 / avg job duration` can help to improve efficiency in a couple of ways:
+
+* Accommodate variability in job durations such that at least 1 minute is filled with synthetics jobs, which is the minimum CronJob duration.
+* Reduce the number of completions cycles to minimize the "nearing the end of completions" inefficiency where the next set of completions can't start until the final job completes.
+
+It's important to note that the `completions` value should not be too large or the CronJob will experience warning events like the following:
+
+```
+8m40s Warning TooManyMissedTimes cronjob/synthetics-node-browser-runtime too many missed start times: 101. Set or decrease .spec.startingDeadlineSeconds or check clock skew
+```
diff --git a/src/i18n/content/jp/docs/accounts/accounts/account-maintenance/query-account-audit-logs-nrauditevent.mdx b/src/i18n/content/jp/docs/accounts/accounts/account-maintenance/query-account-audit-logs-nrauditevent.mdx
index ede77d15bf2..47cddbea5cc 100644
--- a/src/i18n/content/jp/docs/accounts/accounts/account-maintenance/query-account-audit-logs-nrauditevent.mdx
+++ b/src/i18n/content/jp/docs/accounts/accounts/account-maintenance/query-account-audit-logs-nrauditevent.mdx
@@ -44,8 +44,10 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
>
特定の期間におけるNew Relicアカウントへのすべての変更を表示するには、次の基本的なNRQLクエリを実行します。
- ```
- SELECT * from NrAuditEvent SINCE 1 day ago
+ ```sql
+ SELECT *
+ FROM NrAuditEvent
+ SINCE 1 day ago
```
@@ -55,9 +57,11 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
>
アカウントユーザーに対して特定の期間中に最も頻繁に行われた変更の種類を照会するには、照会に[`actionIdentifier`属性](#actorIdentifier)を含めます。例えば：
- ```
- SELECT count(*) AS Actions FROM NrAuditEvent
- FACET actionIdentifier SINCE 1 week ago
+ ```sql
+ SELECT count(*) AS Actions
+ FROM NrAuditEvent
+ FACET actionIdentifier
+ SINCE 1 week ago
```
@@ -67,8 +71,11 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
>
作成されたアカウントとその作成者に関する情報を照会するには、次のようなものを使用できます。
- ```
- SELECT actorEmail, actorId, targetId FROM NrAuditEvent WHERE actionIdentifier = 'account.create' SINCE 1 month ago
+ ```sql
+ SELECT actorEmail, actorId, targetId
+ FROM NrAuditEvent
+ WHERE actionIdentifier = 'account.create'
+ SINCE 1 month ago
```
@@ -78,8 +85,10 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
>
NRQLクエリに`TIMESERIES`を含めると、結果は線グラフとして表示されます。例えば：
- ```
- SELECT count(*) from NrAuditEvent TIMESERIES facet actionIdentifier since 1 week ago
+ ```sql
+ SELECT count(*)
+ FROM NrAuditEvent
+ TIMESERIES facet actionIdentifier since 1 week ago
```
@@ -91,17 +100,20 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
ユーザーに行われたすべての変更を確認するには、次のようにします。
- ```
- SELECT * FROM NrAuditEvent WHERE targetType = 'user'
- SINCE this month
+ ```sql
+ SELECT *
+ FROM NrAuditEvent
+ WHERE targetType = 'user'
+ SINCE this month
```
[ユーザータイプ](/docs/accounts/accounts-billing/new-relic-one-user-management/user-type) の変更点に絞りたい場合は、次のようにします。
- ```
- SELECT * FROM NrAuditEvent WHERE targetType = 'user'
+ ```sql
+ SELECT * FROM NrAuditEvent
+ WHERE targetType = 'user'
AND actionIdentifier IN ('user.self_upgrade', 'user.change_type')
- SINCE this month
+ SINCE this month
```
@@ -111,7 +123,7 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
>
特定の時間枠内の合成モニターの更新を照会するには、照会に[`actionIdentifier`](/attribute-dictionary/nrauditevent/actionidentifier)属性を含めます。例えば：
- ```
+ ```sql
SELECT count(*) FROM NrAuditEvent
WHERE actionIdentifier = 'synthetics_monitor.update_script'
FACET actionIdentifier, description, actorEmail
@@ -127,12 +139,26 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
>
ワークロードに対して行われた構成の変更をクエリするには、以下のクエリを使用します。 `targetId`属性には、検索に使用できる、変更されたワークロードのGUIDが含まれています。ワークロードの変更は自動化されることが多いため、ユーザーがUIまたはAPIを介して直接変更を行ったかどうかを知るために、 `actorType`属性を含めることができます。
- ```
+ ```sql
SELECT timestamp, actorEmail, actorType, description, targetId
- FROM NrAuditEvent WHERE targetType = 'workload'
+ FROM NrAuditEvent
+ WHERE targetType = 'workload'
SINCE 1 week ago LIMIT MAX
```
+
+
+ `targetType` 属性は、アカウント、ロール、ユーザー、アラート条件または通知、ログなど、変更されたオブジェクトを記述します。アカウントの `targetType` 値のリストを生成するには、以下のクエリを実行します。このクエリでは、タッチされた `targetTypes` のみが表示されることに注意してください。
+
+ ```sql
+ SELECT uniques(targetType)
+ FROM NrAuditEvent
+ SINCE 90 days ago
+ ```
+
### 特定のユーザーが行った変更 [#examples-who]
@@ -144,9 +170,10 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
>
特定の期間中にアカウントに変更を加えたユーザーに関する詳細情報を表示するには、クエリに[`actorType = 'user'`](#actorType)を含めます。例えば：
- ```
+ ```sql
SELECT actionIdentifier, description, actorEmail, actorId, targetType, targetId
- FROM NrAuditEvent WHERE actorType = 'user'
+ FROM NrAuditEvent
+ WHERE actorType = 'user'
SINCE 1 week ago
```
@@ -157,8 +184,9 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
>
選択した時間枠内に特定の人が行ったアカウントアクティビティを照会するには、その人の[`actorId`](#actorId)を知っている必要があります。例えば：
- ```
- SELECT actionIdentifier FROM NrAuditEvent
+ ```sql
+ SELECT actionIdentifier
+ FROM NrAuditEvent
WHERE actorId = 829034 SINCE 1 week ago
```
@@ -169,8 +197,9 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
>
アカウントに最も多くの変更を加えた人（ [`actorType`](#actorType) ）を特定するには、クエリに[`actorEmail`属性](#actorEmail)を含めます。例えば：
- ```
- SELECT count(*) as Users FROM NrAuditEvent
+ ```sql
+ SELECT count(*) as Users
+ FROM NrAuditEvent
WHERE actorType = 'user'
FACET actorEmail SINCE 1 week ago
```
@@ -182,7 +211,7 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
>
特定のユーザーによって行われた合成モニターからの更新を照会するには、照会に[`actionIdentifier`](/attribute-dictionary/nrauditevent/actionidentifier) }属性と[`actorEmail`](/attribute-dictionary/nrauditevent/actoremail)属性を含めます。例えば：
- ```
+ ```sql
SELECT count(*) FROM NrAuditEvent
WHERE actionIdentifier = 'synthetics_monitor.update_script'
FACET actorEmail, actionIdentifier, description
@@ -200,9 +229,11 @@ UI のクエリ ビルダーでは、一度に 1 つのアカウントしかク
>
特定の期間中にAPIキーを使用して行われたアカウントへの変更に関する詳細情報を表示するには、クエリに[`actorType = 'api_key'`](#actorType)を含めます。例えば：
- ```
+ ```sql
SELECT actionIdentifier, description, targetType, targetId, actorAPIKey, actorId, actorEmail
- FROM NrAuditEvent WHERE actorType = 'api_key' SINCE 1 week ago
+ FROM NrAuditEvent
+ WHERE actorType = 'api_key'
+ SINCE 1 week ago
```
\ No newline at end of file
diff --git a/src/i18n/content/jp/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial.mdx b/src/i18n/content/jp/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial.mdx
index 5584f70e7f6..04c9177f44f 100644
--- a/src/i18n/content/jp/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial.mdx
+++ b/src/i18n/content/jp/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial.mdx
@@ -12,7 +12,9 @@ translationType: machine
## 要件 [#requirements]
-通常の[NRQLクエリの期間制限](/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries)は1分です。10分の制限でクエリを実行するには、 [DataPlus](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-plus)が必要です。
+[Data Plus](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-plus)をお持ちの場合は、NerdGraph またはクエリ ビルダー UI を使用して、最大 10 分間の非同期クエリを実行できます。
+
+クエリ制限の詳細については、 [「クエリ制限」](/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries/#query-duration)を参照してください。
## 非同期クエリの例 [#example]
diff --git a/src/i18n/content/jp/docs/apm/agents/python-agent/python-agent-api/addcustomattributes-python-agent-api.mdx b/src/i18n/content/jp/docs/apm/agents/python-agent/python-agent-api/addcustomattributes-python-agent-api.mdx
index 1af60780f41..d87f7bf4be0 100644
--- a/src/i18n/content/jp/docs/apm/agents/python-agent/python-agent-api/addcustomattributes-python-agent-api.mdx
+++ b/src/i18n/content/jp/docs/apm/agents/python-agent/python-agent-api/addcustomattributes-python-agent-api.mdx
@@ -84,6 +84,6 @@ def send_request():
```py
# Set server_ip to be the current server processing the transaction
newrelic.agent.add_custom_attributes([
- ("memcache_query_frontend_lookup", "server_ip")
+ ("memcache_query_frontend_lookup", server_ip)
])
```
\ No newline at end of file
diff --git a/src/i18n/content/jp/docs/browser/new-relic-browser/lab/debug-errors.mdx b/src/i18n/content/jp/docs/browser/new-relic-browser/lab/debug-errors.mdx
new file mode 100644
index 00000000000..b641d14c4fd
--- /dev/null
+++ b/src/i18n/content/jp/docs/browser/new-relic-browser/lab/debug-errors.mdx
@@ -0,0 +1,557 @@
+---
+title: 'ラボ パート 3: アプリケーションのエラーをデバッグする'
+metaDescription: 'Part 3 of a multi-part lab on using New Relic browser monitoring to troubleshoot your site: Debug errors in your application'
+translationType: machine
+---
+
+import browserErrors from 'images/browser-lab-screenshot-relicstaurants-browser-errors.webp'
+
+import viewRelicstraunts from 'images/browser-lab-screenshot-view-relicstaurants.webp'
+
+import viewRelicstrauntsBrowser from 'images/browser-lab-screenshot-relicstaurants-browser-app.webp'
+
+import pageWithJSErrors from 'images/browser-lab-screenshot-page-with-js-errors.webp'
+
+import navigateToErrors from 'images/browser-lab-screenshot-navigate-to-js-errors.webp'
+
+import jsErrors from 'images/browser-lab-screenshot-js-errors.webp'
+
+import cartError from 'images/browser-lab-screenshot-cart-error.webp'
+
+import cartErrorDetails from 'images/browser-lab-screenshot-cart-error-details.webp'
+
+import errorInstances from 'images/browser-lab-screenshot-error-instances.webp'
+
+import stackTrace from 'images/browser-lab-screenshot-stack-trace.webp'
+
+import expandStackTrace from 'images/browser-lab-screenshot-expand-stack-trace.webp'
+
+import findFile from 'images/browser-lab-screenshot-find-file.webp'
+
+import unminifedTrace from 'images/browser-lab-screenshot-un-minified.webp'
+
+import noErrors from 'images/browser-lab-screenshot-no-errors.webp'
+
+
+ この手順は、New Relic ブラウザーを使用して Web アプリをトラブルシューティングする方法を説明するラボの一部です。
+
+ ラボの各手順は前回の手順に基づいているため、この手順を開始する前に、最後の手順で [_あるブラウザ エージェントを使用してアプリケーションをインストルメント化するを_](/docs/browser/new-relic-browser/lab/install-browser-agent/)完了していることを確認してください。
+
+
+これまで、アプリケーションは正常に動作していました。ユーザーは注文を行うことができ、サービスに満足しました。しかし、アプリケーションでいくつかの洞察を得たので、いくつかの JavaScript エラーが表示されていることに気付きました。
+
+
+
+この手順では、New Relic ブラウザーを使用してこれらのエラーの原因を突き止め、アプリケーションをタイムリーにデバッグします。
+
+
+ New Relic でデータを表示するには、この手順でブラウザーの監視を有効にする必要があります。
+
+ まだ行っていない場合は、 [ブラウザ エージェントを使用してアプリをインストルメント化します](/docs/browser/new-relic-browser/lab/install-browser-agent)。
+
+
+## フロントエンドエラーをデバッグする
+
+悪いニュースは、アプリケーションにいくつかのエラーがあることを確認したことです。良いニュースは、最近、アプリケーションに当社のブラウザー エージェントを組み込んだことです。アカウントにまだサインインしていない場合は、New Relic に移動してサインインします。
+
+
+
+ New Relic ホームページから **Browser** に移動し、 **Relicstaurants** アプリケーションを選択します。
+
+
+
+
+
+ ここには、ブラウザ アプリケーションに関連するすべてのデータが表示されます。これには、 **JavaScript エラーのあるページ ビュー**、 **主要なウェブ バイタル**、 **サイトでのユーザー時間**、 **最初のページの読み込みとルートの変更**などがあります。
+
+
+
+
+
+ データが表示されませんか?ブラウザーの監視が有効になっており、Load Generator が実行されていることを確認してください。
+
+
+
+ **JavaScript エラーのあるページビューに**注意してください。
+
+
+
+ ここでは、アプリケーションに Javascript エラーがあることを示すスパイクが表示されます。
+
+
+
+ **Page views with javascript errors**\[JavaScript エラーのあるページ ビュー]をクリックします。
+
+
+
+ これにより、 **JS errors**\[JS エラー] ページが表示され、すべての JS エラーと合計エラー インスタンスが表示されます。
+
+
+
+
+
+ 詳細については 、**Cart cannot be empty**\[カートを空にすることはできません] エラーをクリックしてください。
+
+
+
+ ここには、 **errorMessage**、 **INSTANCES**、 **INTERACTIONS AFFECTED** 、およびエラーに関連するその他の詳細が表示されます。
+
+
+
+
+
+ 次に、 **Error Instances**\[エラー インスタンス] タブに移動します。
+
+
+
+ 
+
+ ここには、 **イベント ログ**、 **スタック トレース**など、特定のエラーに関連する詳細が表示されます。
+
+
+
+ **Error Instances**\[エラー インスタンス] ページを下にスクロールして、 **Stack trace**\[スタック トレース]を表示します。
+
+
+
+ ここに、エラーのスタック トレースが表示されます。
+
+
+
+上記のエラーの詳細を見ると、サービスに影響を与える特定のエラーがわかります。ただし、ここに示すスタック トレースは縮小されているため、このエラーの原因を理解するのは困難です。これを理解するには、ソース マップをアップロードしてエラーの縮小を解除する必要があります。
+
+## ソース マップをアップロードして JS エラーを非縮小化する
+
+縮小された JavaScript は、ほとんどの場合、ブラウザーのエラー ページにわかりにくく、役に立たないスタック トレースが表示されます。ソース マップをアップロードすると、これらのエラーがわかりやすいスタック トレースに変換されます。また、コード行への便利なリファレンスを提供し、デバッグを容易にします。UI、API、または npm モジュールを介してソース マップを New Relic にアップロードできます。
+
+ここでは、New Relic UI を使用してソース マップをアップロードし、JS エラーを縮小解除します。
+
+
+
+ JS エラー ページから、エラーのスタック トレースに移動し、展開します。
+
+
+
+ ここに、ソース マップをアップロードするオプションが表示されます。
+
+
+
+ **find file**\[ファイルを検索]をクリックします。
+
+
+
+ これにより、ローカル ストレージからソース マップをアップロードするためのファイル エクスプローラー ウィンドウが開きます。プロジェクトの _build/static/js_ ディレクトリからソース マップを見つけてアップロードします。
+
+
+ ソース マップ ファイルのファイル拡張子は `.js.map`です。Relicstaurants はソース マップを生成するように設定されており、 _build/static/js_ ディレクトリにあります。プロジェクトのソース マップの生成に問題がある場合は、 [ドキュメント](https://docs.newrelic.com/docs/browser/browser-monitoring/browser-pro-features/upload-source-maps-un-minify-js-errors#generate-maps) に従ってソース マップを生成する方法を学習してください。
+
+
+
+
+ ソース マップが正常にアップロードされると、縮小されていないエラーが表示されます。
+
+
+
+ ここに、このエラーを生成している特定のファイルとコード行が表示されます。119 行目で、**Cart cannot be empty!** は _components/layouts/app/app-container/header/app-container-header.js_ ファイルの **onClick** イベントに関連付けられていることに注意してください。ユーザーへのアラートのトリガー。このファイルを詳しく見てみましょう。
+
+
+
+ 選択した IDE でアプリケーションを開き、 _src/components/layouts/app/app-container/header/app-container-header.js_ ファイルに移動します。表示されたコードを詳しく見てください。
+
+ ```js fileName=src/components/layouts/app/app-container/header/app-container-header.js lineHighlight=113-130
+ import { Button, Drawer, Table } from 'antd';
+ import Text from 'antd/lib/typography/Text';
+ import { orderList } from 'atoms/order-list.atom';
+ import { useState } from 'react';
+ import { Link } from 'react-router-dom';
+ import { useRecoilState } from 'recoil';
+ import { Logo, StyledHeader } from './app-header-styled';
+ import Navi from './navi-items';
+ import { useNavigate } from 'react-router';
+
+ const Header = () => {
+ const [isSidebarVisible, setIsSidebarVisible] = useState(false);
+ const [orderListState, setOrderList] = useRecoilState(orderList);
+ const navigate = useNavigate();
+
+ const onClose = () => {
+ setIsSidebarVisible(false);
+ };
+ const handleSidebarOpen = () => {
+ setIsSidebarVisible(true);
+ };
+
+ const itemQuantity = (list) => {
+ let totalItemQuantity = 0;
+ list.forEach((item) => (totalItemQuantity += item.count));
+
+ return totalItemQuantity;
+ };
+
+ const handleDeleteItem = (clickedRow) => {
+ const reducedData = orderListState.filter((item) =>
+ item.name === clickedRow.name ? false : true
+ );
+ setOrderList(reducedData);
+ };
+
+ const columns = [
+ {
+ title: 'Name',
+ dataIndex: 'name',
+ key: 'name',
+ },
+ {
+ title: 'Count',
+ dataIndex: 'count',
+ key: 'count',
+ },
+ {
+ title: 'Price',
+ dataIndex: 'price',
+ key: 'price',
+ },
+ {
+ title: 'Delete',
+ render: (clickedRow) => (
+
+ ),
+ },
+ ];
+
+ return (
+
+
+
+
+ );
+ }
+
+ export default HomeNerdlet
+ ```
+
+
+
+ `useEffect()` 1 秒ごとに `count` 値を自動的に増やします。カウントを自動化したので、インクリメント ボタンも削除しました。
+
+
+
+ ブラウザーに移動して、更新を確認します。
+
+
+
+
+
+## 概要
+
+このガイドでは、次の方法について学習しました。
+
+* ローカルの New Relic Nerdpack を作成する
+* Nerdpack でフックを使用する
\ No newline at end of file
diff --git a/src/i18n/content/jp/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries.mdx b/src/i18n/content/jp/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries.mdx
index d0bedd8a15e..b43c97a418b 100644
--- a/src/i18n/content/jp/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries.mdx
+++ b/src/i18n/content/jp/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries.mdx
@@ -1,41 +1,35 @@
---
-title: NRQLクエリの制限
+title: NRQLクエリのレート制限
metaDescription: 'An explanation of rate limits for NRQL, the New Relic query language'
translationType: machine
---
import queriesnrqlEventCountinQueryBuilder from 'images/queries-nrql_screenshot-crop_event-count-in-query-builder.webp'
-New Relicクエリ言語であるNRQLには、すべてのユーザーに高レベルの可用性と信頼性を保証するためのレート制限があります。
+当社の New Relic クエリ言語 NRQL には、顧客のクエリ速度が他の顧客のエクスペリエンスに影響を与えないように、New Relic 組織ごとにレート制限が設けられています。
-## クエリ制限違反を理解する [#limit-breaches]
+## クエリ制限を超えています [#limit-breaches]
クエリ関連の制限に達しているかどうかを確認するには、[制限UI](/docs/data-apis/manage-data/view-system-limits/)を使用します。
-レート制限に遭遇することはめったにありません。クエリの制限がまれになるようにするために従うべきガイドラインを次に示します。
+NRQL クエリで制限が発生することはほとんどありません。クエリ制限がまれにならないようにするために従うべきガイドラインをいくつか示します。
-* 同時に実行される複雑なクエリ（たとえば、 `FACET`または`TIMESERIES`句を含むクエリ、または100万を超えるイベントのクエリ）の数を制限します。
+* 同時に実行する複雑なクエリ (たとえば、 `FACET` 句や `TIMESERIES` 句を含むクエリ、または 100 万を超えるイベントのクエリ) の数を制限します。
* 特に複雑なクエリが含まれている場合は、長期間にわたって同時に実行されるクエリの数を最大5つに制限します。
## NRQLクエリの制限 [#query-limits]
-いくつかの異なるNRQLクエリ制限があります。
+以下については制限があります。
-* アカウントが特定の時間範囲内に実行できるクエリの数
-* アカウントが特定の時間範囲でクエリ（検査）できるデータポイントの数
-* エラーと見なされて停止するまでのクエリの実行時間
+* 特定の時間範囲内でクエリできるデータ ポイントの数
+* エラーが発生して停止するまでにクエリを実行できる時間
+* 特定の時間範囲内に実行できるクエリの数
-これらの制限は、クエリビルダーを使用したクエリ、カスタムチャートやダッシュボードで使用されるクエリ、NerdGraph APIを使用して実行されるNRQLクエリなど、顧客が開始するNRQLクエリにのみ適用されることに注意してください。これらの制限は、事前に作成された「すぐに使える」NewRelicチャートおよびダッシュボードで使用されるクエリには適用されません。
+次に、これらの制限について詳しく説明します。
-### クエリ数の制限 [#query-count-limits]
+## 検査されるデータポイントの制限 [#inspected-count-limits]
-NRQLクエリの制限は、アカウントごと、1分あたり3,000クエリです。この制限を超えると、1分あたりに送信されるクエリの数が制限を超えなくなるまで、クエリが拒否される場合があります。
-
-この制限は、NRQLクエリAPIリクエストにのみ適用され、クエリビルダー、New Relic UI、またはカスタムダッシュボードから実行されるクエリには適用されません。New Relic UI、クエリビルダー、またはカスタマーダッシュボードで実行されるこのカテゴリのクエリのリソース消費率を管理する制限は、検査済みのカウント制限のみです。
-
-### 検査されるデータポイントの数の制限 [#inspected-count-limits]
-
-NRQLクエリを実行すると、以下に示すように、検査されたデータポイントの数が表示されます。
+顧客主導のクエリまたは UI ページの読み込みにより NRQL クエリが実行されると、そのクエリは NRDB データベース内の特定の数のデータ ポイントを検査します。たとえば、NRQL クエリを実行すると、左下に示すように、検査されたデータ ポイントの数が表示されます。
-このコンテキストでは、「イベント」という用語は、クエリで検査されるすべての[NRQLで使用可能なデータポイント](/docs/query-data/nrql-new-relic-query-language/getting-started/introduction-nrql#what-you-can-query)を指すために一般的な意味で使用されます。
+
+ このコンテキストでは、 `events` クエリによって検査されるすべての [NRQL に保存されたデータポイント](/docs/query-data/nrql-new-relic-query-language/getting-started/introduction-nrql#what-you-can-query) を指します。
+
-すべてのNewRelicアカウントには、特定の時間範囲で検査できるデータポイントの総数に制限があります。これらの制限は、使用している[データオプション](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-prices)によって異なります。
+検査されるカウント制限は、特定の時間範囲内にクエリできるデータ ポイントの数を表します。これらの制限は、どの [データ オプションが](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-prices) あるかによって異なります。
-### 検査済みイベントの制限には何がカウントされますか? [#define-inspected-count]
+### 検査数には何がカウントされますか? [#what-counts-inspected-count]
-以下は、検査数の制限にカウントされ、制限に達すると影響を受ける機能とアクションです。次の期間にカウントが制限を下回ると、制限が解除されます。
+次のアクションは、New Relic アカウントの検査数制限にカウントされます。
-* ユーザーによって開始された精選されたビューのロード (たとえば、
+* ユーザーによって開始された厳選されたビューの負荷 (たとえば、
- UI ページ、分散トレース UI、ブラウザー監視 UI ページ、または組織に関するデータを返す任意の UI)。
+ UI ページ、分散トレーシング UI、または組織に関するデータを返す任意の UI)。
+
+* New Relic ユーザーによって、UI または API 経由で実行されるカスタム クエリ。
-* New Relic ユーザーが実行するカスタム クエリ (NRQL または NerdGraph)。
+* カスタム ダッシュボードでクエリを実行するウィジェットの読み込み
-* クエリを実行するカスタム ダッシュボードのウィジェット。
+アラート条件の評価と通知は制限にカウントされ **ません** が、アラート通知に含まれる New Relic へのリンクはカウントされます。
-* アラート条件の評価と通知は制限にカウントされ **ません** が、アラート通知に含まれる New Relic へのリンクはカウントされます。
+検査数の制限に達すると、前述の機能が影響を受けます。次の期間にカウントが制限を下回ると、制限はすべて解除されます。
-### クエリ期間の制限 [#query-duration]
+## クエリ期間の制限 [#query-duration]
-クエリ期間の制限は、NRQLクエリが実行を停止するまでに実行できる時間です。この制限は、 [データオプション](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-prices)によって異なります。
+クエリ期間制限は、NRQL クエリが実行を停止してエラーとみなされるまでに実行できる時間です。この制限は [データ オプション](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-prices)によって異なります。
* 元のデータオプション：1分
* データプラス：
- * 通常のNRQLクエリで2分
- * [非同期クエリ](/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial)を使用して10分
\ No newline at end of file
+ * 10 分 ([クエリ ビルダー](/docs/query-your-data/explore-query-data/query-builder/introduction-query-builder) または [NerdGraph](/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial)を使用)
+ * クエリ ビルダー以外の他の UI の場所で 2 分
+
+## クエリ数の制限 [#query-count-limits]
+
+この制限は、API 経由で実行される NRQL クエリにのみ適用され、UI から実行されるクエリには適用されません。
+
+この制限は、1 アカウントあたり 1 分あたり 3,000 クエリです。この制限を超えると、クエリの数が制限を超えなくなるまでクエリは拒否される場合があります。
\ No newline at end of file
diff --git a/src/i18n/content/jp/docs/service-level-management/create-slm.mdx b/src/i18n/content/jp/docs/service-level-management/create-slm.mdx
index 6a794970812..9de67c880a3 100644
--- a/src/i18n/content/jp/docs/service-level-management/create-slm.mdx
+++ b/src/i18n/content/jp/docs/service-level-management/create-slm.mdx
@@ -134,7 +134,7 @@ SLIは、有効なリクエストの総数のうち、良いレスポンスの
```sql
FROM: TransactionError
- WHERE: entityGuid = '{entityGuid}' AND error.expected IS FALSE
+ WHERE: entityGuid = '{entityGuid}' AND error.expected != true
```
ここで、 `{entityGuid}`はサービスのGUIDです。
diff --git a/src/i18n/content/kr/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx b/src/i18n/content/kr/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx
index a7c0aea5aae..2f82c160530 100644
--- a/src/i18n/content/kr/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx
+++ b/src/i18n/content/kr/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts.mdx
@@ -80,7 +80,7 @@ translationType: machine
## 데이터 수집 및 쿼리 제한 [#data-limits]
-데이터 수집 제한 및 쿼리 제한에 대한 자세한 내용은 [쿼리 시스템 제한](/docs/data-apis/manage-data/query-limits) 을 참조하십시오.
+데이터 수집 제한 및 쿼리 제한에 대한 자세한 내용은 [New Relic 데이터 제한을](/docs/data-apis/manage-data/view-system-limits) 참조하세요.
## 사용자 수 쿼리 [#user-queries]
diff --git a/src/i18n/content/kr/docs/accounts/accounts/account-maintenance/query-account-audit-logs-nrauditevent.mdx b/src/i18n/content/kr/docs/accounts/accounts/account-maintenance/query-account-audit-logs-nrauditevent.mdx
index 68bbf01ecf9..96eea23b092 100644
--- a/src/i18n/content/kr/docs/accounts/accounts/account-maintenance/query-account-audit-logs-nrauditevent.mdx
+++ b/src/i18n/content/kr/docs/accounts/accounts/account-maintenance/query-account-audit-logs-nrauditevent.mdx
@@ -44,8 +44,10 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
>
특정 기간 동안 New Relic 계정에 대한 모든 변경 사항을 보려면 다음 기본 NRQL 쿼리를 실행하십시오.
- ```
- SELECT * from NrAuditEvent SINCE 1 day ago
+ ```sql
+ SELECT *
+ FROM NrAuditEvent
+ SINCE 1 day ago
```
@@ -55,9 +57,11 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
>
특정 기간 동안 계정 사용자에게 어떤 유형의 변경이 가장 자주 발생했는지 쿼리하려면 쿼리에 [`actionIdentifier` 속성](#actorIdentifier) 을 포함하세요. 예를 들어:
- ```
- SELECT count(*) AS Actions FROM NrAuditEvent
- FACET actionIdentifier SINCE 1 week ago
+ ```sql
+ SELECT count(*) AS Actions
+ FROM NrAuditEvent
+ FACET actionIdentifier
+ SINCE 1 week ago
```
@@ -67,8 +71,11 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
>
생성된 계정 및 생성자에 대한 정보를 쿼리하려면 다음과 같이 사용할 수 있습니다.
- ```
- SELECT actorEmail, actorId, targetId FROM NrAuditEvent WHERE actionIdentifier = 'account.create' SINCE 1 month ago
+ ```sql
+ SELECT actorEmail, actorId, targetId
+ FROM NrAuditEvent
+ WHERE actionIdentifier = 'account.create'
+ SINCE 1 month ago
```
@@ -78,8 +85,10 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
>
NRQL 쿼리에 `TIMESERIES` 을 포함하면 결과가 선 그래프로 표시됩니다. 예를 들어:
- ```
- SELECT count(*) from NrAuditEvent TIMESERIES facet actionIdentifier since 1 week ago
+ ```sql
+ SELECT count(*)
+ FROM NrAuditEvent
+ TIMESERIES facet actionIdentifier since 1 week ago
```
@@ -91,17 +100,20 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
사용자에 대한 모든 변경 사항을 보려면 다음을 사용할 수 있습니다.
- ```
- SELECT * FROM NrAuditEvent WHERE targetType = 'user'
- SINCE this month
+ ```sql
+ SELECT *
+ FROM NrAuditEvent
+ WHERE targetType = 'user'
+ SINCE this month
```
[사용자 유형](/docs/accounts/accounts-billing/new-relic-one-user-management/user-type) 에 대한 변경 사항을 보기 위해 범위를 좁히려면 다음을 사용할 수 있습니다.
- ```
- SELECT * FROM NrAuditEvent WHERE targetType = 'user'
+ ```sql
+ SELECT * FROM NrAuditEvent
+ WHERE targetType = 'user'
AND actionIdentifier IN ('user.self_upgrade', 'user.change_type')
- SINCE this month
+ SINCE this month
```
@@ -111,7 +123,7 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
>
특정 기간 동안 합성 모니터에 대한 업데이트를 쿼리하려면 쿼리에 [`actionIdentifier`](/attribute-dictionary/nrauditevent/actionidentifier) 속성을 포함합니다. 예를 들어:
- ```
+ ```sql
SELECT count(*) FROM NrAuditEvent
WHERE actionIdentifier = 'synthetics_monitor.update_script'
FACET actionIdentifier, description, actorEmail
@@ -127,12 +139,26 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
>
워크로드에 적용된 구성 변경 사항을 쿼리하려면 아래 쿼리를 사용하십시오. `targetId` 속성에는 검색에 사용할 수 있는 수정된 워크로드의 GUID가 포함됩니다. 워크로드에 대한 변경은 종종 자동화되므로 `actorType` 속성을 포함하여 사용자가 UI 또는 API를 통해 직접 변경했는지 알 수 있습니다.
- ```
+ ```sql
SELECT timestamp, actorEmail, actorType, description, targetId
- FROM NrAuditEvent WHERE targetType = 'workload'
+ FROM NrAuditEvent
+ WHERE targetType = 'workload'
SINCE 1 week ago LIMIT MAX
```
+
+
+ `targetType` 속성은 계정, 역할, 사용자, 경고 조건 또는 알림, 로그 등 변경된 개체를 설명합니다. 귀하의 계정에 대한 `targetType` 값 목록을 생성하려면 아래 쿼리를 실행하십시오. 이 쿼리에는 터치된 `targetTypes` 만 표시됩니다.
+
+ ```sql
+ SELECT uniques(targetType)
+ FROM NrAuditEvent
+ SINCE 90 days ago
+ ```
+
### 특정 사용자가 변경한 사항 [#examples-who]
@@ -144,9 +170,10 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
>
특정 기간 동안 계정을 변경한 사용자에 대한 자세한 정보를 보려면 쿼리에 [`actorType = 'user'`](#actorType) 을 포함합니다. 예를 들어:
- ```
+ ```sql
SELECT actionIdentifier, description, actorEmail, actorId, targetType, targetId
- FROM NrAuditEvent WHERE actorType = 'user'
+ FROM NrAuditEvent
+ WHERE actorType = 'user'
SINCE 1 week ago
```
@@ -157,8 +184,9 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
>
선택한 기간 동안 특정 개인이 수행한 계정 활동을 쿼리하려면 해당 [`actorId`](#actorId) 를 알아야 합니다. 예를 들어:
- ```
- SELECT actionIdentifier FROM NrAuditEvent
+ ```sql
+ SELECT actionIdentifier
+ FROM NrAuditEvent
WHERE actorId = 829034 SINCE 1 week ago
```
@@ -169,8 +197,9 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
>
계정을 가장 많이 변경한 사람( [`actorType`](#actorType) )을 식별하려면 쿼리에 [`actorEmail` 속성](#actorEmail) 을 포함하십시오. 예를 들어:
- ```
- SELECT count(*) as Users FROM NrAuditEvent
+ ```sql
+ SELECT count(*) as Users
+ FROM NrAuditEvent
WHERE actorType = 'user'
FACET actorEmail SINCE 1 week ago
```
@@ -182,7 +211,7 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
>
특정 사용자가 만든 합성 모니터에서 업데이트를 쿼리하려면 쿼리에 [`actionIdentifier`](/attribute-dictionary/nrauditevent/actionidentifier) 및 [`actorEmail`](/attribute-dictionary/nrauditevent/actoremail) 속성을 포함합니다. 예를 들어:
- ```
+ ```sql
SELECT count(*) FROM NrAuditEvent
WHERE actionIdentifier = 'synthetics_monitor.update_script'
FACET actorEmail, actionIdentifier, description
@@ -200,9 +229,11 @@ UI의 쿼리 빌더는 한 번에 하나의 계정만 쿼리할 수 있습니다
>
특정 기간 동안 API 키를 사용하여 이루어진 계정 변경에 대한 자세한 정보를 보려면 쿼리에 [`actorType = 'api_key'`](#actorType) 을 포함하십시오. 예를 들어:
- ```
+ ```sql
SELECT actionIdentifier, description, targetType, targetId, actorAPIKey, actorId, actorEmail
- FROM NrAuditEvent WHERE actorType = 'api_key' SINCE 1 week ago
+ FROM NrAuditEvent
+ WHERE actorType = 'api_key'
+ SINCE 1 week ago
```
\ No newline at end of file
diff --git a/src/i18n/content/kr/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial.mdx b/src/i18n/content/kr/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial.mdx
index d8f6d12e755..65f3678bcfc 100644
--- a/src/i18n/content/kr/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial.mdx
+++ b/src/i18n/content/kr/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial.mdx
@@ -12,7 +12,9 @@ translationType: machine
## 요구 사항 [#requirements]
-일반적인 [NRQL 쿼리 기간 제한](/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries) 은 1분입니다. 10분 제한으로 쿼리를 실행하려면 [Data Plus](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-plus) 가 있어야 합니다.
+[Data Plus](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-plus) 가 있는 경우 NerdGraph 또는 쿼리 빌더 UI를 사용하여 최대 10분 동안 비동기 쿼리를 실행할 수 있습니다.
+
+쿼리 제한에 대한 자세한 내용은 [쿼리 제한을](/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries/#query-duration) 참조하세요.
## 비동기 쿼리 예제 [#example]
diff --git a/src/i18n/content/kr/docs/apm/agents/python-agent/python-agent-api/addcustomattributes-python-agent-api.mdx b/src/i18n/content/kr/docs/apm/agents/python-agent/python-agent-api/addcustomattributes-python-agent-api.mdx
index d9547e5c0d8..8d8d1f36f60 100644
--- a/src/i18n/content/kr/docs/apm/agents/python-agent/python-agent-api/addcustomattributes-python-agent-api.mdx
+++ b/src/i18n/content/kr/docs/apm/agents/python-agent/python-agent-api/addcustomattributes-python-agent-api.mdx
@@ -84,6 +84,6 @@ def send_request():
```py
# Set server_ip to be the current server processing the transaction
newrelic.agent.add_custom_attributes([
- ("memcache_query_frontend_lookup", "server_ip")
+ ("memcache_query_frontend_lookup", server_ip)
])
```
\ No newline at end of file
diff --git a/src/i18n/content/kr/docs/apm/apm-ui-pages/events/record-deployments.mdx b/src/i18n/content/kr/docs/apm/apm-ui-pages/events/record-deployments.mdx
index 3ded4d0edc2..f3425f64cfa 100644
--- a/src/i18n/content/kr/docs/apm/apm-ui-pages/events/record-deployments.mdx
+++ b/src/i18n/content/kr/docs/apm/apm-ui-pages/events/record-deployments.mdx
@@ -319,42 +319,10 @@ New Relic REST API v2를 사용하여 배포를 기록하고 과거 배포 목
* **Python** : `newrelic-admin` 스크립트의 [`record-deploy`](/docs/agents/python-agent/installation-configuration/python-agent-admin-script#record-deploy) 하위 명령을 사용합니다.
* **Ruby** : [Capistrano 조리법](/docs/agents/ruby-agent/features/recording-deployments-ruby-agent#capistrano3) 을 사용하십시오.
-## 배포에 대해 팀에 알리기 [#webhooks]
-
-배포가 기록된 후 REST API 또는 최신 [GraphQL API를](/docs/change-tracking/change-tracking-introduction)통해 웹후크를 사용하여 팀원에게 알릴 수 있습니다.
-
-배포 데이터를 다양한 웹후크 대상으로 보낼 수 있습니다. Slack을 제외하고 사용 중인 도구에 대한 지침을 따르기만 하면 됩니다. Slack 웹후크를 사용하려면 다음과 같이 New Relic Slack 앱 대신 레거시 New Relic Alerts 앱을 사용해야 합니다.
-
-1. Slack 계정에 관리자로 로그인한 다음 **앱**으로 이동합니다.
-2. **New Relic Alerts 를**검색하고 해당 타일이 나타나면 클릭합니다.
-3. **New Relic Alerts** 목록에서 New Relic 아이콘 아래에 있는 **구성** 버튼을 클릭합니다.
-4. **New Relic Alerts** 제목 아래에 있는 **구성**탭을 클릭합니다.
-5. **구성** 탭에서 연필 아이콘을 클릭합니다.
-6. **Webhook URL** 섹션까지 아래로 스크롤하고 **URL 복사를**클릭합니다.
-7. **[one.newrelic.com > All capabilties](https://one.newrelic.com/all-capabilities) > ([사용자 메뉴](/docs/accounts/accounts-billing/general-account-settings/intro-account-settings)) > Administration > Integrations > Deploy notifications** 으로 이동합니다.
-8. Slack 웹후크 URL을 **웹후크 URL**에 붙여넣습니다.
-9. **웹후크와 통합을**클릭합니다.
-
## 배포 세부정보 보기 [#dep_procedures]
-
- 이 섹션과 다음 섹션에서는 현재 배포 마커 UI를 사용하는 방법에 대해 설명합니다. UI에 제한된 미리 보기에 있다는 파란색 배너가 표시되면 새 UI에 액세스할 수 있습니다. 이 경우 이러한 새 [지침](/docs/apm/apm-ui-pages/events/change-tracking/deployments-page-view-impact-your-app-users/) 으로 전환하십시오.
-
+배포 정보를 구성한 후 UI에서 세부 정보를 보고 드릴다운할 수 있습니다. 팁을 보려면 변경 추적 문서 [New Relic에서 변경 사항을 보고 분석하는 방법을](/docs/change-tracking/change-tracking-view-analyze) 참조하세요.
-배포 정보를 구성한 후 세부 정보를 보고 드릴다운할 수 있습니다.
-
-1. **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > APM & services > (앱 선택) > Events > Deployments** 으로 이동합니다.
-2. 자세한 정보를 드릴다운하려면 New Relic의 표준 [사용자 인터페이스 기능](/docs/data-analysis/user-interface-functions/standard-page-functions) 을 사용하십시오.
-3. 특정 이벤트에 대한 세부 정보를 보려면 해당 **날짜** 링크를 선택하십시오.
-4. 이 배포에 대한 오류 페이지를 보려면 **오류** 링크를 선택하십시오.
-5. 해당하는 경우 특정 배포에 대한 세부 정보를 보려면 **로그** **변경 또는 보고서** 변경 을 선택합니다.
-
-**변경 로그** 에는 [배포를 기록](/docs/apm/new-relic-apm/maintenance/recording-deployments) 할 때 `changelog` 매개변수를 통해 제공된 모든 세부정보가 포함됩니다. **변경 보고서** 는 배포 전후의 상위 10개 트랜잭션의 동작을 표시합니다.
-
-## 배포 후 성능 보기 [#dep_timepicker]
-
-개별 배포에 대한 **배포** 페이지 링크는 **이벤트** 섹션에서 선택한 앱의 [요약](/docs/applications-menu/applications-overview) 페이지에 나타납니다. 14일보다 짧은 기간의 경우 차트의 파란색 세로 막대는 배포를 나타냅니다. 배포에 대한 요약 정보를 보려면 파란색 막대 위로 마우스를 가져갑니다.
+## 배포에 대해 팀에 알리기 [#webhooks]
-
- APM 요약 페이지에서 **비교** 대상 옵션을 사용하여 동일한 데이터를 비교할 기간을 선택할 수도 있습니다. **비교 대상** 을 활성화하면 UI에 배포 마커가 표시되지 않습니다.
-
\ No newline at end of file
+REST API 또는 최신 [GraphQL API를](/docs/change-tracking/change-tracking-introduction) 사용하여 배포를 추적하는지 여부에 관계없이 웹후크를 사용하여 팀 구성원에게 알릴 수 있습니다. 자세한 내용은 변경 사항 추적 [웹훅 지침을](/docs/change-tracking/change-tracking-webhooks) 참조하세요.
\ No newline at end of file
diff --git a/src/i18n/content/kr/docs/browser/new-relic-browser/lab/debug-errors.mdx b/src/i18n/content/kr/docs/browser/new-relic-browser/lab/debug-errors.mdx
new file mode 100644
index 00000000000..248d0abc3a7
--- /dev/null
+++ b/src/i18n/content/kr/docs/browser/new-relic-browser/lab/debug-errors.mdx
@@ -0,0 +1,557 @@
+---
+title: '랩 파트 3: 애플리케이션의 오류 디버그'
+metaDescription: 'Part 3 of a multi-part lab on using New Relic browser monitoring to troubleshoot your site: Debug errors in your application'
+translationType: machine
+---
+
+import browserErrors from 'images/browser-lab-screenshot-relicstaurants-browser-errors.webp'
+
+import viewRelicstraunts from 'images/browser-lab-screenshot-view-relicstaurants.webp'
+
+import viewRelicstrauntsBrowser from 'images/browser-lab-screenshot-relicstaurants-browser-app.webp'
+
+import pageWithJSErrors from 'images/browser-lab-screenshot-page-with-js-errors.webp'
+
+import navigateToErrors from 'images/browser-lab-screenshot-navigate-to-js-errors.webp'
+
+import jsErrors from 'images/browser-lab-screenshot-js-errors.webp'
+
+import cartError from 'images/browser-lab-screenshot-cart-error.webp'
+
+import cartErrorDetails from 'images/browser-lab-screenshot-cart-error-details.webp'
+
+import errorInstances from 'images/browser-lab-screenshot-error-instances.webp'
+
+import stackTrace from 'images/browser-lab-screenshot-stack-trace.webp'
+
+import expandStackTrace from 'images/browser-lab-screenshot-expand-stack-trace.webp'
+
+import findFile from 'images/browser-lab-screenshot-find-file.webp'
+
+import unminifedTrace from 'images/browser-lab-screenshot-un-minified.webp'
+
+import noErrors from 'images/browser-lab-screenshot-no-errors.webp'
+
+
+ 이 절차는 New Relic 브라우저로 웹 앱의 문제를 해결하는 방법을 알려주는 랩의 일부입니다.
+
+ 랩의 각 절차는 마지막 절차를 기반으로 하므로 이 절차를 시작하기 전에 마지막 절차인 [_브라우저 에이전트로 애플리케이션 계측을_](/docs/browser/new-relic-browser/lab/install-browser-agent/)완료했는지 확인하십시오.
+
+
+지금까지 애플리케이션이 제대로 작동했습니다. 사용자가 주문할 수 있었고 귀하의 서비스에 만족했습니다. 그러나 이제 애플리케이션에 약간의 통찰력이 있으므로 일부 JavaScript 오류가 표시되고 있음을 알 수 있습니다.
+
+
+
+이 절차에서는 New Relic 브라우저를 사용하여 이러한 오류의 원인을 찾고 적시에 애플리케이션을 디버깅합니다.
+
+
+ New Relic에서 데이터를 보려면 이 절차에 대해 브라우저 모니터링을 활성화해야 합니다.
+
+ 아직 하지 않았다면 [브라우저 에이전트로 앱을 계측하십시오](/docs/browser/new-relic-browser/lab/install-browser-agent).
+
+
+## 프런트엔드 오류 디버그
+
+안타까운 소식은 애플리케이션에 몇 가지 오류가 있음을 확인했다는 것입니다. 좋은 소식은 최근에 브라우저 에이전트로 애플리케이션을 계측했다는 것입니다! 아직 로그인하지 않은 경우 New Relic으로 이동하여 계정에 로그인합니다.
+
+
+
+ New Relic 홈페이지에서 **Browser** 로 이동하여 **Relicstaurants** 애플리케이션을 선택합니다.
+
+
+
+
+
+ 여기에서 **Page views with JavaScript errors**\[JavaScript 오류가 있는 페이지 보기], **Core web vitals**\[핵심 웹 바이탈], **User time on the site**\[사이트의 사용자 시간], **Initial page load and route changes**\[초기 페이지 로드 및 경로 변경]등을 포함하여 브라우저 애플리케이션과 관련된 모든 데이터를 볼 수 있습니다.
+
+
+
+
+
+ 데이터가 보이지 않습니까? 브라우저 모니터링을 활성화했고 부하 생성기가 실행 중인지 확인하십시오.
+
+
+
+ **Page views with javascript errors**\[자바스크립트 오류가 있는 공지 페이지 ] 보기.
+
+
+
+ 여기에서 애플리케이션에 일부 Javascript 오류가 있음을 나타내는 스파이크가 표시됩니다.
+
+
+
+ **Page views with javascript errors**\[자바스크립트 오류가 있는 페이지 보기를] 클릭합니다.
+
+
+
+ 총 오류 인스턴스와 함께 모든 JS 오류를 볼 수 있는 **JS errors**\[JS 오류] 페이지로 이동합니다.
+
+
+
+
+
+ 자세한 내용을 보려면 **Cart cannot be empty** 오류를 클릭하십시오.
+
+
+
+ 여기에서 **errorMessage**, **INSTANCES**, **INTERACTIONS AFFECTED** 및 오류와 관련된 기타 세부 정보를 볼 수 있습니다.
+
+
+
+
+
+ 그런 다음 **Error Instances**\[오류 인스턴스] 탭으로 이동합니다.
+
+
+
+ 
+
+ 여기에서 **Event Log**\[이벤트 로그], **Stack trace**\[스택 추적] 및 기타를 포함하여 특정 오류와 관련된 자세한 내용을 볼 수 있습니다.
+
+
+
+ **Error Instances**\[오류 인스턴스] 페이지에서 아래로 스크롤하여 **Stack trace**\[스택 추적을]봅니다.
+
+
+
+ 여기에서 오류의 스택 추적을 볼 수 있습니다.
+
+
+
+위의 오류 세부 정보를 보면 이제 서비스에 영향을 미치는 특정 오류를 알 수 있습니다. 그러나 여기에 표시된 스택 추적은 축소되었으며 이 오류의 원인을 이해하기 어렵습니다. 이를 이해하려면 소스 맵을 업로드하여 오류 축소를 해제해야 합니다.
+
+## JS 오류를 축소 해제하기 위해 소스 맵 업로드
+
+축소된 JavaScript는 대부분 브라우저의 오류 페이지에서 이해하기 어렵고 쓸모 없는 스택 추적을 생성합니다. 소스 맵을 업로드하면 이러한 오류가 이해할 수 있는 스택 추적으로 변환됩니다. 또한 코드 라인에 대한 유용한 참조를 제공하고 디버깅을 더 쉽게 만듭니다. UI, API 또는 npm 모듈을 통해 소스 맵을 New Relic에 업로드할 수 있습니다.
+
+여기서는 New Relic UI를 사용하여 소스 맵을 업로드하고 JS 오류를 축소 해제합니다.
+
+
+
+ JS 오류 페이지에서 오류의 스택 추적으로 이동하여 확장합니다.
+
+
+
+ 여기에 소스 맵을 업로드하는 옵션이 표시됩니다.
+
+
+
+ **find file**\[파일 찾기를]클릭합니다.
+
+
+
+ 이렇게 하면 로컬 저장소에서 소스 맵을 업로드할 수 있는 파일 탐색기 창이 열립니다. 프로젝트의 _build/static/js_ 디렉터리에서 소스 맵을 찾아 업로드합니다.
+
+
+ 소스 맵 파일의 파일 확장자는 `.js.map`입니다. Relicstaurants는 소스 맵을 생성하도록 설정되어 있으며 _build/static/js_ 디렉토리에서 찾을 수 있습니다. 프로젝트에 대한 소스 맵을 생성하는 데 문제가 있는 경우 [설명서를](https://docs.newrelic.com/docs/browser/browser-monitoring/browser-pro-features/upload-source-maps-un-minify-js-errors#generate-maps) 따라 생성 방법을 알아보세요.
+
+
+
+
+ 소스 맵이 성공적으로 업로드되면 오류가 축소되지 않은 것을 볼 수 있습니다.
+
+
+
+ 여기에서 이 오류를 생성하는 특정 파일과 코드 줄을 볼 수 있습니다. 119행에서 **Cart cannot be empty!**\[Cart는 비워둘 수 없습니다!] ****_components/layouts/app/app-container/header/app-container-header.js_ 파일의 **onClick** 이벤트와 연결되어 있으며 사용자에 대한 경고도 트리거합니다. 이 파일을 자세히 살펴보겠습니다!
+
+
+
+ 선택한 IDE에서 애플리케이션을 열고 _src/components/layouts/app/app-container/header/app-container-header.js_ 파일로 이동합니다. 표시된 코드를 자세히 살펴보십시오.
+
+ ```js fileName=src/components/layouts/app/app-container/header/app-container-header.js lineHighlight=113-130
+ import { Button, Drawer, Table } from 'antd';
+ import Text from 'antd/lib/typography/Text';
+ import { orderList } from 'atoms/order-list.atom';
+ import { useState } from 'react';
+ import { Link } from 'react-router-dom';
+ import { useRecoilState } from 'recoil';
+ import { Logo, StyledHeader } from './app-header-styled';
+ import Navi from './navi-items';
+ import { useNavigate } from 'react-router';
+
+ const Header = () => {
+ const [isSidebarVisible, setIsSidebarVisible] = useState(false);
+ const [orderListState, setOrderList] = useRecoilState(orderList);
+ const navigate = useNavigate();
+
+ const onClose = () => {
+ setIsSidebarVisible(false);
+ };
+ const handleSidebarOpen = () => {
+ setIsSidebarVisible(true);
+ };
+
+ const itemQuantity = (list) => {
+ let totalItemQuantity = 0;
+ list.forEach((item) => (totalItemQuantity += item.count));
+
+ return totalItemQuantity;
+ };
+
+ const handleDeleteItem = (clickedRow) => {
+ const reducedData = orderListState.filter((item) =>
+ item.name === clickedRow.name ? false : true
+ );
+ setOrderList(reducedData);
+ };
+
+ const columns = [
+ {
+ title: 'Name',
+ dataIndex: 'name',
+ key: 'name',
+ },
+ {
+ title: 'Count',
+ dataIndex: 'count',
+ key: 'count',
+ },
+ {
+ title: 'Price',
+ dataIndex: 'price',
+ key: 'price',
+ },
+ {
+ title: 'Delete',
+ render: (clickedRow) => (
+
+ ),
+ },
+ ];
+
+ return (
+
+
+
+
Relicstaurants
+
by New Relic
+
+
+
+
+
{
+ let totalPrice = 0;
+
+ pageData.forEach(
+ ({ price, count }) => (totalPrice += price * count)
+ );
+
+ return (
+ <>
+
+ Total
+
+ {totalPrice.toFixed(2)}
+
+
+
+
+
+
+
+
+
+
+
+ );
+ }}
+ />
+
+
+ );
+ };
+
+ export default Header;
+
+ ```
+
+ 여기에서 **Cart cannot be empty!**\[장바구니는 비워둘 수 없다는] 오류에 유의하십시오 사용자가 실수로 빈 장바구니로 결제를 시도할 때만 발생합니다. 이 기능은 최종 사용자에게 빈 장바구니로 결제를 진행할 수 없음을 알리도록 코딩되어 있습니다. 이제 이 오류가 서비스에 영향을 미치지 않는다는 것을 알고 있습니다. 그러나 이 엣지 케이스를 처리하고 오류를 방지하는 더 좋은 방법이 있습니다.
+
+
+
+ 애플리케이션 제공을 중지하려면 애플리케이션을 실행 중인 터미널에서 `Ctrl+C` 누르세요. 다음과 같이 _src/components/layouts/app/app-container/header/app-container-header.js를_ 업데이트합니다.
+
+ ```js fileName=src/components/layouts/app/app-container/header/app-container-header.js lineHighlight=4,81-134
+ import { Button, Drawer, Table } from 'antd';
+ import Text from 'antd/lib/typography/Text';
+ import { orderList } from 'atoms/order-list.atom';
+ import { Message } from 'components/common';
+ import { useState } from 'react';
+ import { Link } from 'react-router-dom';
+ import { useRecoilState } from 'recoil';
+ import { Logo, StyledHeader } from './app-header-styled';
+ import Navi from './navi-items';
+ import { useNavigate } from 'react-router';
+
+ const Header = () => {
+ const [isSidebarVisible, setIsSidebarVisible] = useState(false);
+ const [orderListState, setOrderList] = useRecoilState(orderList);
+ const navigate = useNavigate();
+
+ const onClose = () => {
+ setIsSidebarVisible(false);
+ };
+ const handleSidebarOpen = () => {
+ setIsSidebarVisible(true);
+ };
+
+ const itemQuantity = (list) => {
+ let totalItemQuantity = 0;
+ list.forEach((item) => (totalItemQuantity += item.count));
+
+ return totalItemQuantity;
+ };
+
+ const handleDeleteItem = (clickedRow) => {
+ const reducedData = orderListState.filter((item) =>
+ item.name === clickedRow.name ? false : true
+ );
+ setOrderList(reducedData);
+ };
+
+ const columns = [
+ {
+ title: 'Name',
+ dataIndex: 'name',
+ key: 'name',
+ },
+ {
+ title: 'Count',
+ dataIndex: 'count',
+ key: 'count',
+ },
+ {
+ title: 'Price',
+ dataIndex: 'price',
+ key: 'price',
+ },
+ {
+ title: 'Delete',
+ render: (clickedRow) => (
+
+ ),
+ },
+ ];
+
+ return (
+
+
+
+
Relicstaurants
+
by New Relic
+
+
+
+
+ {orderListState.length > 0 ? (
+
{
+ let totalPrice = 0;
+
+ pageData.forEach(
+ ({ price, count }) => (totalPrice += price * count)
+ );
+
+ return (
+ <>
+
+ Total
+
+ {totalPrice.toFixed(2)}
+
+
+
+
+
+
+
+
+
+
+
+ );
+ }}
+ />
+ ) : (
+ Nothing in cart
+ )}
+
+
+ );
+ };
+
+ export default Header;
+
+ ```
+
+
+
+여기에서 카트가 비어 있을 때 오류 대신 **Nothing in cart**\[카트에 아무것도 없음] 메시지를 표시하는 파일을 수정했습니다. **PAY** 버튼은 최종 사용자가 장바구니에 항목을 담을 때까지 비활성화된 상태로 유지됩니다.
+
+## 애플리케이션 다시 시작
+
+애플리케이션을 수정했으므로 이제 로컬 서버를 다시 시작할 차례입니다.
+
+```bash
+npm run build
+npm run newstart
+```
+
+부하 생성기도 다시 시작하십시오.
+
+```bash
+python3 simulator.py
+```
+
+
+ 올바른 터미널 창에서 이러한 명령을 실행하고 있는지 확인하십시오. 해당 창이 더 이상 없으면 [설정 절차](/docs/browser/new-relic-browser/lab/set-up-env)의 단계를 따르십시오.
+
+
+부하 생성기가 New Relic으로 데이터를 전송하기 시작하면 애플리케이션에서 더 이상 JavaScript 오류를 보고하지 않는다는 점에 유의하십시오.
+
+
+
+## 요약
+
+요약하자면, 애플리케이션에서 오류를 발견하고 New Relic 브라우저를 사용하여 다음을 수행했습니다.
+
+1. 오류율 검토
+2. 애플리케이션의 JS 오류 분석
+3. 오류 인스턴스 이해
+4. 소스 맵을 업로드하여 JS 오류 디버그
+
+
+ 이 절차는 New Relic 브라우저로 웹 앱의 문제를 해결하는 방법을 알려주는 랩의 일부입니다. 다음으로 [애플리케이션에서 프런트엔드 속도 저하를 디버깅해](/docs/browser/new-relic-browser/lab/debug-slowness/)보십시오.
+
\ No newline at end of file
diff --git a/src/i18n/content/kr/docs/browser/new-relic-browser/lab/install-browser-agent.mdx b/src/i18n/content/kr/docs/browser/new-relic-browser/lab/install-browser-agent.mdx
new file mode 100644
index 00000000000..0672b560c65
--- /dev/null
+++ b/src/i18n/content/kr/docs/browser/new-relic-browser/lab/install-browser-agent.mdx
@@ -0,0 +1,186 @@
+---
+title: '랩 파트 2: 애플리케이션 계측'
+description: 'New Relic 브라우저 모니터링을 사용하여 사이트를 개선하는 방법에 대한 여러 부분으로 구성된 랩의 파트 2: React 애플리케이션 계측'
+translationType: machine
+---
+
+import addData from 'images/browser-lab-screenshot-add-data.webp'
+
+import browser from 'images/browser-lab-screenshot-newrelic-browser.webp'
+
+import selectDeploymentMethod from 'images/browser-lab-screenshot-select-deployment-method.webp'
+
+import enableBrowser from 'images/browser-lab-screenshot-enable-browser.webp'
+
+import browserCodeSnippet from 'images/browser-lab-screenshot-browser-code-snippet.webp'
+
+import viewRelicstraunts from 'images/browser-lab-screenshot-view-relicstaurants.webp'
+
+import viewRelicstrauntsBrowser from 'images/browser-lab-screenshot-relicstaurants-browser-app.webp'
+
+
+ 이 절차는 New Relic 브라우저 모니터링으로 웹 앱의 문제를 해결하는 방법을 알려주는 랩의 일부입니다.
+
+ 랩의 각 절차는 마지막 절차를 기반으로 하므로 이 절차를 시작하기 전에 마지막 절차인 [랩 환경 설정을](/docs/browser/new-relic-browser/lab/set-up-env/)완료했는지 확인하십시오.
+
+
+이제 React 앱이 브라우저에서 실행되고 있습니다. 사용자가 사이트에서 항상 최상의 경험을 하도록 해야 합니다. 이를 위해서는 페이지 로드 시간과 같은 사용자 경험에 대한 통찰력이 필요합니다.
+
+이 목표를 달성하려면 브라우저 에이전트를 설치해야 합니다.
+
+## 브라우저 에이전트 설치
+
+
+
+ [New Relic](https://one.newrelic.com/)으로 이동하여 계정으로 로그인합니다.
+
+
+
+ 상단 탐색 모음의 오른쪽에서 **Add data**\[데이터 추가] 를클릭합니다.
+
+
+
+
+
+ **Browser & mobile**\[브라우저 및 모바일] 까지 아래로 스크롤하고 **Browser monitoring**\[브라우저 모니터링을]선택합니다.
+
+
+
+ UI는 브라우저 에이전트 설치 과정을 안내합니다.
+
+
+
+ 배포 방법으로 **Copy/paste JavaScript code**\[JavaScript 코드 복사/붙여넣기를] 선택합니다.
+
+
+
+
+
+ **Name your app**\[앱 이름 지정]까지 아래로 스크롤합니다. 앱 이름을 **Relicstaurants**로지정하고 **Enable**을클릭합니다.
+
+
+
+ 이렇게 하면 브라우저 모니터링을 활성화하는 JavaScript 코드 스니펫이 제공됩니다. 클립보드에 복사합니다.
+
+
+
+
+
+ 선택한 IDE에서 앱을 엽니다.
+
+ 앱의 _public/index.html_ 파일에서 복사한 자바스크립트 스니펫을 ``안에 붙여넣습니다.
+
+ ```html lineHighlight=22-23 fileName=public/index.html
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Relicstaurants
+
+
+
+
+
+
+
+
+
+
+ ```
+
+ 귀하의 애플리케이션은 이제 브라우저 에이전트로 계측됩니다.
+
+
+
+## 애플리케이션 다시 시작
+
+애플리케이션을 구성했으므로 이제 로컬 서버를 다시 시작할 차례입니다.
+
+```bash
+npm run build
+npm run newstart
+```
+
+부하 생성기도 다시 시작하십시오.
+
+```bash
+python3 simulator.py
+```
+
+
+ 올바른 터미널 창에서 이러한 명령을 실행하고 있는지 확인하십시오. 해당 창이 더 이상 없으면 [설정 절차](/docs/browser/new-relic-browser/lab/set-up-env)의 단계를 따르십시오.
+
+
+## 데이터 보기
+
+이제 앱이 브라우저 데이터를 New Relic으로 전송하고 있습니다. **Browser**\[브라우저]아래의 New Relic에서 이 데이터를 봅니다.
+
+
+
+ [New Relic](https://one.newrelic.com/) 으로 이동하여 계정으로 로그인합니다.
+
+
+
+ 왼쪽 탐색 모음에서 **Browser** 로 이동하여 **Relicstaurants**를선택합니다.
+
+
+
+ 여기에서 **Page views with JavaScript errors**\[JavaScript 오류가 있는 페이지 보기], **Core web vitals**\[핵심 웹 바이탈], **User time on the site**\[사이트의 사용자 시간], **Initial page load and route changes**\[초기 페이지 로드 및 경로 변경], 앱의 기타 성능 데이터를 볼 수 있습니다.
+
+
+
+
+
+브라우저 에이전트를 사용하여 브라우저 데이터를 New Relic으로 보내도록 애플리케이션을 구성했습니다. 또한 New Relic에서 성능 데이터를 볼 수 있습니다. 다음으로 이 데이터를 사용하여 사이트의 프런트 엔드 오류 문제를 해결합니다.
+
+
+ 이 절차는 New Relic 브라우저 모니터링으로 웹 앱의 문제를 해결하는 방법을 알려주는 랩의 일부입니다. 이제 브라우저 에이전트로 애플리케이션을 계측했으므로 [오류를 디버그합니다](/docs/browser/new-relic-browser/lab/debug-errors/).
+
\ No newline at end of file
diff --git a/src/i18n/content/kr/docs/browser/new-relic-browser/lab/set-up-env.mdx b/src/i18n/content/kr/docs/browser/new-relic-browser/lab/set-up-env.mdx
new file mode 100644
index 00000000000..4a083447f92
--- /dev/null
+++ b/src/i18n/content/kr/docs/browser/new-relic-browser/lab/set-up-env.mdx
@@ -0,0 +1,161 @@
+---
+title: '랩 파트 1: 랩 환경 설정'
+metaDescription: 'Part 1 of a multi-part lab on troubleshooting your website: Spin up your test app and simulator'
+translationType: machine
+---
+
+import homepage from 'images/browser-lab-screenshot-homepage.webp'
+
+import restaurantList from 'images/browser-lab-screenshot-restaurant-list.webp'
+
+import chooseRestaurant from 'images/browser-lab-screenshot-choose-restaurant.webp'
+
+import selectFood from 'images/browser-lab-screenshot-select-food.webp'
+
+import checkout from 'images/browser-lab-screenshot-checkout.webp'
+
+import placeOrder from 'images/browser-lab-screenshot-place-order.webp'
+
+import thankYou from 'images/browser-lab-screenshot-thank-you.webp'
+
+
+ 이 절차는 New Relic 브라우저로 웹 앱의 문제를 해결하는 방법을 알려주는 랩의 일부입니다. 아직 확인하지 않았다면 [실습 소개를](/docs/browser/new-relic-browser/lab/over-view/)확인하세요.
+
+
+실습을 제대로 진행하려면 먼저 React 애플리케이션을 가동해야 합니다. 여기에서 당신은:
+
+* React 애플리케이션 가동
+* 간단한 로드 생성기를 사용하여 앱에 트래픽 보내기
+
+
+
+ 터미널 창을 열고 랩 리포지토리를 복제합니다.
+
+ ```bash
+ git clone https://github.com/newrelic-experimental/relicstaurants.git
+ ```
+
+
+
+ 애플리케이션의 루트 디렉터리로 이동하여 lab 디렉터리로 전환합니다.
+
+
+ ```bash
+ cd relicstaurants
+ git switch browser-pro-lab-material
+ ```
+
+
+ 다음으로 종속성을 설치하고 애플리케이션을 실행합니다.
+
+ ```bash
+ npm install
+ npm run build
+ npm run newstart
+ ```
+
+ 이렇게 하면 브라우저에서 Relicstaurants 애플리케이션이 열립니다.
+
+
+
+ 배달 주소를 입력하고 레스토랑을 검색하여 시작하세요.
+
+
+
+ 여기에서 음식을 주문할 수 있는 레스토랑 목록을 볼 수 있습니다.
+
+
+
+ 식당을 선택하세요.
+
+
+
+
+
+ 항목을 한두 개 선택하고 카트를 클릭합니다.
+
+
+
+
+
+ **PAY**\[지불을]클릭합니다.
+
+
+
+
+
+ 아래 가짜 카드 정보를 입력하고 **Finish payment**\[결제 완료를] 클릭하여 주문하십시오.
+
+
+
+ 주문이 완료되었습니다.
+
+
+
+ 다음으로 시뮬레이터를 사용하여 애플리케이션에 더 많은 트래픽을 생성합니다.
+
+
+
+ 다른 터미널 창에서 애플리케이션의 루트 디렉터리로 이동하고 부하 생성기를 실행합니다.
+
+ ```bash
+ # Navigate to the root directiory of your simulator
+ cd relicstaurants/simulator
+ # Switch to lab branch
+ git switch browser-pro-lab-material
+ [output]
+ # Install the simulator's dependencies
+ pip3 install -r requirements.txt
+ [output]
+ # Run the simulator
+ python3 simulator.py
+ [output] ====== WebDriver manager ======
+ [output] Current google-chrome version is 99.0.4844
+ [output] Get LATEST chromedriver version for 99.0.4844 google-chrome
+ ```
+
+
+ 이 부하 생성기는 컴퓨터에 Google Chrome이 설치되어 있다고 가정합니다. 다른 브라우저를 사용하는 경우 이 단계를 건너뛰고 수동으로 트래픽을 생성하거나 [Google 크롬을 설치하세요](https://www.google.com/chrome/downloads/).
+
+
+
+
+이제 응용 프로그램을 실행하는 방법을 알았으니 계측할 차례입니다. 애플리케이션과 시뮬레이터를 실행 중인 터미널 창에서 `` 를 눌러 종료합니다. 앱이 종료되면 코드를 업데이트하여 모니터링 도구를 도입할 수 있습니다.
+
+
+ 이 절차는 New Relic 브라우저로 웹 앱의 문제를 해결하는 방법을 알려주는 랩의 일부입니다. 이제 환경을 설정했으므로 [브라우저 에이전트로 애플리케이션을 계측합니다](/docs/browser/new-relic-browser/lab/install-browser-agent/).
+
\ No newline at end of file
diff --git a/src/i18n/content/kr/docs/change-tracking/change-tracking-view-analyze.mdx b/src/i18n/content/kr/docs/change-tracking/change-tracking-view-analyze.mdx
index 675a1749167..07ef118db90 100644
--- a/src/i18n/content/kr/docs/change-tracking/change-tracking-view-analyze.mdx
+++ b/src/i18n/content/kr/docs/change-tracking/change-tracking-view-analyze.mdx
@@ -28,6 +28,8 @@ import trackingComparisonCurves from 'images/tracking_screenshot-crop_comparison
import trackingCustomChartsonDeploymentPage from 'images/tracking_screenshot-crop_custom-charts-on-deployment-page.webp'
+import trackingWebTransactionsImpact from 'images/tracking_screenshot-crop_impacts_to_web-transactions.webp'
+
New Relic의 변경 사항 추적 기능을 사용하면 배포와 같은 최근 변경 사항이 최종 사용자에게 어떤 영향을 미치는지 확인할 수 있습니다. 예를 들어 앱 서버 Apdex 점수, 응답 시간, 처리량 및 오류를 볼 수 있습니다. 세부 정보를 보고 드릴다운하고, 검색 및 정렬 옵션을 사용하고, 오류를 숨기거나 삭제하고, 다른 사람과 공유하거나, 관련 티켓을 제출할 수 있습니다.
변경 사항의 영향을 보고 분석하는 방법에 대한 세부 정보로 이동하기 전에 GraphQL, CLI 또는 CI/CD 통합을 사용하여 모니터링할 변경 사항을 지정했는지 확인하세요. 추적할 변경 사항을 지정하고 나면 여러 가지 방법으로 스택 전체에서 결과를 볼 수 있습니다.
@@ -194,6 +196,23 @@ New Relic의 거의 모든 위치(차트, **문제** 페이지 등)에서 배포
5. **What do you want to track** \[무엇을 추적하시겠습니까?]를 클릭하고 지표 또는 이벤트를 선택합니다.
6. **How do you want to aggregate that?**\[어떻게 집계하시겠습니까?]를 클릭합니다. 기능을 선택합니다.
+### 웹 트랜잭션에 대한 변경 사항의 영향을 확인하세요. [#web-transactions]
+
+변경 내용 추적을 사용하면 APM 애플리케이션 변경이 웹 트랜잭션에 어떤 영향을 미쳤는지에 대한 세부 정보를 확인할 수 있습니다. APM 애플리케이션의 변경 사항을 추적할 때 **Web transaction impacts** \[웹 트랜잭션 영향이라는] 제목이 표시됩니다. 이 섹션의 표에는 애플리케이션에서 가장 많은 시간이 소요되는 최대 10개의 웹 트랜잭션에 대한 성능 지표가 나와 있습니다.
+
+
+
+테이블에 표시되는 내용을 제어하려면 다음을 수행하세요.
+
+* **Metric** \[측정항목] 드롭다운을 사용하여 이 추적된 변경 사항이 다양한 측정항목에 어떤 영향을 미치는지 확인하세요.
+* 표에서 전후 기간을 변경함에 따라 변경 후 기간이 향후 종료될 경우 불완전한 거래 데이터가 표시될 수 있다는 점을 유의하시기 바랍니다.
+* 추적된 다른 변경 사항을 나란히 비교하여 표에 표시하려면 **compared with** \[와 비교] 에서 다른 변경 사항을 선택합니다.
+* **Transaction name** \[거래 이름] 열의 값 위로 마우스를 가져가면 해당 거래에 대한 5개 지표 모두의 성과를 요약하는 도구 설명이 표시됩니다. 도구 설명에는 APM 거래 세부 정보에 대한 링크도 있으므로 자세한 거래 수준 데이터를 자세히 알아볼 수 있습니다.
+
## 쿼리 배포 데이터 [#query-deployments]
NRQL(New Relic 데이터베이스용 쿼리 언어) 또는 NerdGraph(New Relic GraphQL API)를 통해 배포 데이터를 쿼리할 수도 있습니다.
@@ -366,6 +385,6 @@ GraphQL을 사용하여 마커를 생성한 후 [쿼리 빌더](/docs/query-your
-아직 하지 않았다면 아래에서 무료 New Relic 계정을 만들어 오늘 데이터 모니터링을 시작하십시오.
+## 다음은 뭐지? [#what-next]
-
\ No newline at end of file
+팀에 배포에 대해 알리려면 웹후크를 설정하는 것이 좋습니다. [배포에 대해 팀에 알리기 를](/docs/change-tracking/change-tracking-webhooks) 참조하세요.
\ No newline at end of file
diff --git a/src/i18n/content/kr/docs/change-tracking/change-tracking-webhooks.mdx b/src/i18n/content/kr/docs/change-tracking/change-tracking-webhooks.mdx
new file mode 100644
index 00000000000..f0b1f8f0635
--- /dev/null
+++ b/src/i18n/content/kr/docs/change-tracking/change-tracking-webhooks.mdx
@@ -0,0 +1,142 @@
+---
+title: 배포에 대해 팀에 알리기
+tags:
+ - APM
+metaDescription: 'After you set up the changes you want to monitor, you can use a webhook to notify your colleagues about the impacts of those changes.'
+translationType: machine
+---
+
+import webHookTest from 'images/tracking_screenshot-crop_webhook_test.webp'
+
+APM 애플리케이션 엔터티에 대한 배포를 기록한 후에는 웹후크를 사용하여 해당 변경 사항에 대한 정보를 팀에 계속 알릴 수 있습니다. 변경 사항 추적 기능을 사용하여 배포를 기록하든지 이전 [REST API를](/docs/apm/apm-ui-pages/events/record-deployments/#api-instructions) 사용하든 상관없이 이러한 기능을 사용할 수 있습니다.
+
+## 웹훅 도착 URL 가져오기 [#get-webhook-url]
+
+배포 데이터를 다양한 웹훅 대상으로 보낼 수 있습니다. 웹훅 URL을 얻으려면 사용 중인 도구에 대한 지침을 따르세요. URL이 있으면 다음 섹션의 단계를 완료하여 웹훅 알림을 구성하세요.
+
+Slack을 사용하는 경우 여기 지침에 따라 레거시 New Relic 알림 앱을 설정하세요.
+
+1. Slack 계정에 관리자로 로그인한 다음 **앱**으로 이동합니다.
+2. **New Relic Alerts** 를 검색하고 해당 타일을 클릭하세요.
+3. **New Relic Alerts** 목록에서 New Relic 아이콘 아래에 있는 **구성** 버튼을 클릭합니다.
+4. **New Relic Alerts** 제목 아래에 있는 **구성**탭을 클릭합니다.
+5. **구성** 탭에서 연필 아이콘을 클릭합니다.
+6. **Webhook URL** 섹션까지 아래로 스크롤하고 **URL 복사를**클릭합니다.
+
+## 배포를 위한 웹훅 알림 구성 [#configure-webhook]
+
+New Relic UI에 웹훅 URL을 삽입합니다.
+
+1. 배포 알림 구성 화면으로 이동합니다: **[one.newrelic.com](https://one.newrelic.com/) > (사용자 메뉴) > Administration > Integrations > Deploy notifications**.
+
+2. 웹훅 URL을 **Webhook URL** \[웹훅 URL] 필드에 붙여넣고 **Save** \[저장을] 클릭하세요.
+
+3. **Send a test request** \[테스트 요청 보내기를] 클릭하여 인공 데이터가 포함된 예제 페이로드를 웹후크 URL로 보냅니다.
+
+
+
+4. **Toggle this webhook** 에서 토글을 밀어 웹훅 알림을 비활성화하거나 다시 활성화할 수 있습니다.
+
+5. 웹훅 알림 구성을 영구적으로 삭제하려면 **Delete this webhook** \[이 웹훅 삭제 를] 클릭하세요.
+
+## 알림 페이로드 구조 [#payload-structure]
+
+배포 알림이 활성화되고 배포를 생성하면 웹훅은 `application/x-www-form-urlencoded` 유형의 페이로드가 포함된 `POST` 요청을 수신합니다. 키와 값은 `&` 로 구분된 키-값 튜플로 인코딩되며 키와 값 사이에는 `=` 기호가 있습니다. 키와 값 모두에서 영숫자가 아닌 문자는 URL로 인코딩됩니다.
+
+배포 및 배포된 APM 애플리케이션 엔터티의 특성을 기반으로 다음 키와 값이 전송됩니다.
+
+
+
+
+
+ 열쇠
+
+
+
+ 값
+
+
+
+
+
+
+
+ 생성\_시간
+
+
+
+ ISO 8601 형식의 배포 타임스탬프
+
+
+
+
+
+ 애플리케이션\_이름
+
+
+
+ APM 애플리케이션 엔터티의 이름
+
+
+
+
+
+ 계정\_이름
+
+
+
+ APM 애플리케이션 엔터티를 소유한 계정의 이름
+
+
+
+
+
+ 변경 로그
+
+
+
+ 배포에 포함된 변경 사항 목록
+
+
+
+
+
+ description
+
+
+
+ 배포에 대한 설명
+
+
+
+
+
+ 개정
+
+
+
+ 배포된 소프트웨어 버전
+
+
+
+
+
+ 배포\_URL
+
+
+
+ APM 애플리케이션 엔터티의 배포 UI에 대한 링크
+
+
+
+
+
+ 배포\_기준
+
+
+
+ 애플리케이션을 배포한 사용자
+
+
+
+
\ No newline at end of file
diff --git a/src/i18n/content/kr/docs/data-apis/manage-data/query-limits.mdx b/src/i18n/content/kr/docs/data-apis/manage-data/query-limits.mdx
index dbf3e1043a8..58021ff8a97 100644
--- a/src/i18n/content/kr/docs/data-apis/manage-data/query-limits.mdx
+++ b/src/i18n/content/kr/docs/data-apis/manage-data/query-limits.mdx
@@ -1,5 +1,5 @@
---
-title: 쿼리 시스템 제한
+title: 데이터 한도에 대해 자세히 알아보세요.
tags:
- Ingest data manage data
- Manage data
diff --git a/src/i18n/content/kr/docs/data-apis/manage-data/view-system-limits.mdx b/src/i18n/content/kr/docs/data-apis/manage-data/view-system-limits.mdx
index b1a16cd3e1b..a69907e8cdf 100644
--- a/src/i18n/content/kr/docs/data-apis/manage-data/view-system-limits.mdx
+++ b/src/i18n/content/kr/docs/data-apis/manage-data/view-system-limits.mdx
@@ -1,5 +1,5 @@
---
-title: 데이터 수집 및 쿼리 제한 이해
+title: New Relic 데이터 제한 이해
tags:
- Ingest and manage data
- Manage data
diff --git a/src/i18n/content/kr/docs/kubernetes-pixie/auto-telemetry-pixie/advanced-configuration/manage-pixie-memory.mdx b/src/i18n/content/kr/docs/kubernetes-pixie/auto-telemetry-pixie/advanced-configuration/manage-pixie-memory.mdx
index 32832e4bfe6..91ed9b2223d 100644
--- a/src/i18n/content/kr/docs/kubernetes-pixie/auto-telemetry-pixie/advanced-configuration/manage-pixie-memory.mdx
+++ b/src/i18n/content/kr/docs/kubernetes-pixie/auto-telemetry-pixie/advanced-configuration/manage-pixie-memory.mdx
@@ -19,10 +19,10 @@ Pixie가 사용하는 메모리 양을 구성할 수 있습니다. 설치하는
[오픈 소스 Pixie 프로젝트](https://github.com/pixie-io/pixie) 의 주요 초점은 실시간 디버깅 플랫폼을 구축하는 것입니다. Pixie [는 장기 내구성 저장 솔루션을 위한 것이 아니며](https://docs.px.dev/about-pixie/faq/#data-collection-how-much-data-does-pixie-store) New Relic과 함께 사용하는 것이 가장 좋습니다. New Relic 통합은 몇 분마다 Pixie를 쿼리하고 New Relic에서 Pixie의 원격 측정 데이터 하위 집합을 유지합니다.
-New Relic Pixie 통합을 설치하면 DaemonSet를 통해 클러스터의 각 노드에 `vizier-pem` 에이전트가 배포됩니다. `vizier-pem` 에이전트는 두 가지 주요 목적으로 메모리를 사용합니다.
+New Relic Pixie 통합을 설치하면 [`vizier-pem` 에이전트가](https://docs.px.dev/reference/architecture/#vizier) DaemonSet를 통해 클러스터의 각 노드에 배포됩니다. `vizier-pem` 에이전트는 두 가지 주요 목적으로 메모리를 사용합니다.
-* **원격 측정 데이터 수집** : 무엇보다도 애플리케이션 트래픽 또는 CPU 프로필 추적. 이러한 값은 처리될 때 메모리 어딘가에 저장되어야 합니다.
-* **원격 측정 데이터의 단기 저장** :[Pixie 탭으로 라이브 디버깅을](/docs/kubernetes-pixie/auto-telemetry-pixie/understand-use-data/live-debugging-with-pixie) 통해 문제 해결을 강화합니다. 그리고 New Relic에 저장되기 전에 원격 측정 데이터의 하위 집합에 대한 임시 저장 위치로 사용됩니다.
+* **Collecting telemetry data** \[원격 측정 데이터 수집]: 애플리케이션 트래픽이나 CPU 프로필 등을 추적합니다. 해당 값은 처리되는 동안 메모리 어딘가에 저장되어야 합니다.
+* **Short-term storage of telemetry data** \[원격 측정 데이터의 단기 저장]:[Pixie 탭을 사용한 라이브 디버깅을](/docs/kubernetes-pixie/auto-telemetry-pixie/understand-use-data/live-debugging-with-pixie) 통해 문제 해결을 지원하고 New Relic에 저장되기 전에 원격 측정 데이터의 하위 집합에 대한 임시 저장 위치로 사용됩니다.
기본적으로 `vizier-pem` 포드에는 `2Gi` 메모리 제한과 `2Gi` 메모리 요청이 있습니다. 할당된 메모리의 60%를 단기 데이터 저장에 할당하고 나머지 40%는 데이터 수집을 위해 남겨둡니다.
diff --git a/src/i18n/content/kr/docs/kubernetes-pixie/auto-telemetry-pixie/pixie-data-security-overview.mdx b/src/i18n/content/kr/docs/kubernetes-pixie/auto-telemetry-pixie/pixie-data-security-overview.mdx
index 2f2145ab92d..b53cf8b7120 100644
--- a/src/i18n/content/kr/docs/kubernetes-pixie/auto-telemetry-pixie/pixie-data-security-overview.mdx
+++ b/src/i18n/content/kr/docs/kubernetes-pixie/auto-telemetry-pixie/pixie-data-security-overview.mdx
@@ -10,7 +10,7 @@ metaDescription: null
translationType: machine
---
-Pixie를 사용한 자동 원격 측정은 Pixie 오픈 소스 소프트웨어의 관리 버전인 Community Cloud for Pixie를 통합한 것입니다. 따라서 Pixie를 사용한 자동 원격 측정은 데이터를 안전하게 유지하는 Pixie의 접근 방식을 활용합니다. Pixie가 수집하는 데이터는 전적으로 Kubernetes 클러스터 내에 저장됩니다. 이 데이터는 사용자 환경 외부에서 지속되지 않으며 Pixie용 Community Cloud에 저장되지 않습니다. 이는 민감한 데이터가 환경 및 제어 범위 내에 남아 있음을 의미합니다.
+Pixie를 사용한 자동 원격 측정은 Pixie 오픈 소스 소프트웨어의 관리형 버전인 [Pixie용 Community Cloud를](https://docs.px.dev/installing-pixie/install-guides/community-cloud-for-pixie/) 통합한 것입니다. 따라서 Pixie를 사용한 자동 원격 측정은 데이터 보안을 유지하는 Pixie의 접근 방식을 활용합니다. Pixie가 수집하는 데이터는 Kubernetes 클러스터 내에 완전히 저장됩니다. 이 데이터는 환경 외부에 유지되지 않으며 Pixie용 Community Cloud에 저장되지 않습니다. 이는 귀하의 민감한 데이터가 귀하의 환경 및 통제 내에 남아 있음을 의미합니다.
Community Cloud for Pixie는 Kubernetes 클러스터에 직접 쿼리하여 데이터에 액세스합니다. 쿼리 결과가 Pixie UI, CLI 및 API용 커뮤니티 클라우드에 표시되도록 하기 위해 데이터는 역방향 프록시를 사용하여 클러스터에서 클라이언트로 전송됩니다.
@@ -19,7 +19,7 @@ Community Cloud for Pixie의 역방향 프록시는 다음을 보장하도록
* 데이터는 일시적입니다. 전송 중인 Pixie의 클라우드 프록시용 Community Cloud만 통과합니다. 이것은 데이터 지역성을 보장합니다.
* 데이터는 전송 중에 암호화됩니다. 당신만이 당신의 데이터를 읽을 수 있습니다.
-New Relic은 애플리케이션의 성능과 관련된 데이터를 가져와 저장합니다. Pixie를 사용한 자동 원격 측정을 사용하면 사전 정의된 데이터 하위 집합이 클러스터 외부에 유지됩니다. 이 데이터는 선택한 지역의 데이터베이스에 저장됩니다. 이 데이터는 장기 저장, 경고, 추가 데이터와의 상관 관계, 이상 감지와 같은 고급 New Relic 플랫폼 기능을 사용할 수 있는 기능을 제공하기 위해 유지됩니다.
+New Relic은 애플리케이션 성능과 관련된 데이터를 가져오고 저장합니다. Pixie를 사용한 자동 원격 측정을 사용하면 사전 정의된 데이터 하위 집합이 클러스터 외부에 유지됩니다. 이 데이터는 귀하가 선택한 지역의 당사 데이터베이스에 저장됩니다. 이 데이터는 장기간 저장, 경고, 추가 데이터와의 상관 관계, 이상 [탐지](/docs/alerts-applied-intelligence/applied-intelligence/anomaly-detection/anomaly-detection-applied-intelligence/) 와 같은 고급 New Relic 플랫폼 기능을 사용할 수 있는 기능을 제공하기 위해 지속됩니다.
지속되는 성능 지표에는 다음이 포함되지만 이에 국한되지는 않습니다.
diff --git a/src/i18n/content/kr/docs/kubernetes-pixie/kubecost/get-started-kubecost.mdx b/src/i18n/content/kr/docs/kubernetes-pixie/kubecost/get-started-kubecost.mdx
index a5732d5f514..8ca0e1cf65d 100644
--- a/src/i18n/content/kr/docs/kubernetes-pixie/kubecost/get-started-kubecost.mdx
+++ b/src/i18n/content/kr/docs/kubernetes-pixie/kubecost/get-started-kubecost.mdx
@@ -21,7 +21,7 @@ New Relic 및 [Kubecost를](https://kubecost.github.io/cost-analyzer/) 사용하
## 시작하다
-Kubecost 및 New Relic을 시작하려면 New Relic에서 Prometheus Remote Write를 설정해야 합니다. 그런 다음 Kubecost 에이전트를 설치해야 합니다.
+시작하려면 먼저 New Relic에서 [Prometheus Remote Write를](/docs/infrastructure/prometheus-integrations/install-configure-remote-write/set-your-prometheus-remote-write-integration/) 설정한 다음 Kubecost 에이전트를 설치하세요.
### Prometheus 원격 쓰기 설정
@@ -33,7 +33,7 @@ Kubecost 및 New Relic을 시작하려면 New Relic에서 Prometheus Remote Writ
### 클러스터에 Kubecost 에이전트 설치
-이제 Helm을 통해 Kubecost 에이전트를 설치하겠습니다.
+다음으로 Helm을 통해 Kubecost 에이전트를 설치합니다.
1. Kubecost 에이전트 설치를 위한 템플릿 YAML 파일을 다운로드합니다. `kubecost-values.yaml` 에 저장합니다.
@@ -1177,7 +1177,7 @@ extraObjects: []
2. 선택한 편집기에서 `kubecost-values.yaml` 엽니다.
3. 671행으로 이동하고 이전 단계에서 Prometheus Remote Write 통합을 위해 생성한 URL 값을 포함하도록 `YOUR_URL_HERE` 를 업데이트합니다. `https://metric-api.newrelic.com/prometheus/v1/write?prometheus_server=kubecost` 와 같아야 합니다.
4. 672행으로 이동하고 이전 단계에서 Prometheus 원격 쓰기 통합을 위해 생성한 전달자 토큰의 값을 포함하도록 `YOUR_BEARER_TOKEN_HERE` 를 업데이트합니다.
-5. Helm 명령을 실행하여 Kubecost 에이전트를 클러스터에 추가합니다. New Relic으로 데이터 전송을 시작해야 합니다.
+5. 아래 Helm 명령을 실행하여 Kubecost 에이전트를 클러스터에 추가하고 New Relic으로 데이터 전송을 시작하세요.
```shell
helm upgrade --install kubecost \ [11:13:30]
@@ -1186,8 +1186,8 @@ helm upgrade --install kubecost \
--values kubecost-values.yaml
```
-6. 몇 분만 기다리세요. 원격 쓰기 설정 이전 탭에서 "내 데이터 보기" 버튼을 클릭하여 데이터 수신 여부를 확인합니다.
-7. 데이터를 쿼리합니다.
+6. 몇 분만 기다리세요. 원격 쓰기를 설정한 이전 탭에서 **See your data** \[데이터 보기] 버튼을 클릭하여 데이터 수신 여부를 확인하세요.
+7. 데이터 쿼리:
```sql
SELECT sum(`Total Cost($)`) AS 'Total Monthly Cost' FROM (FROM Metric SELECT (SELECT sum(`total_node_cost`) FROM (FROM Metric SELECT (average(kube_node_status_capacity_cpu_cores) * average(node_cpu_hourly_cost) * 730 + average(node_gpu_hourly_cost) * 730 + average(kube_node_status_capacity_memory_bytes) / 1024 / 1024 / 1024 * average(node_ram_hourly_cost) * 730) AS 'total_node_cost' FACET node)) + (SELECT (sum(acflb) / 1024 / 1024 / 1024 * 0.04) AS 'Container Cost($)' FROM (SELECT (average(container_fs_limit_bytes) * cardinality(container_fs_limit_bytes)) AS 'acflb' FROM Metric WHERE (NOT ((device = 'tmpfs')) AND (id = '/')))) + (SELECT sum(aphc * 730 * akpcb / 1024 / 1024 / 1024) AS 'Total Persistent Volume Cost($)' FROM (FROM Metric SELECT average(pv_hourly_cost) AS 'aphc', average(kube_persistentvolume_capacity_bytes) AS 'akpcb' FACET persistentvolume, instance)) AS 'Total Cost($)')
diff --git a/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/changes-since-v3.mdx b/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/changes-since-v3.mdx
index 5cb47bfe219..76d8508e70e 100644
--- a/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/changes-since-v3.mdx
+++ b/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/changes-since-v3.mdx
@@ -8,9 +8,9 @@ metaDescription: Changes introduced in Kubernetes Integration version 3
translationType: machine
---
-버전 3부터 New Relic의 Kubernetes 솔루션은 모듈화 및 구성 가능성을 목표로 하는 [아키텍처](/docs/kubernetes-pixie/kubernetes-integration/get-started/kubernetes-components/#architecture) 를 특징으로 하여 솔루션 배포 방법을 선택할 수 있는 더 많은 권한을 제공하고 더 많은 환경과 호환되도록 합니다.
+버전 3부터 New Relic Kubernetes 통합은 보다 모듈화되고 구성 가능한 것을 목표로 하는 [아키텍처](/docs/kubernetes-pixie/kubernetes-integration/get-started/kubernetes-components/#architecture) 를 특징으로 하여 배포 방법을 선택할 수 있는 더 많은 권한을 제공하고 더 많은 환경과 호환되도록 합니다.
-Kubernetes 통합 버전 3에서 보고한 데이터는 버전 2 이후로 변경되지 않았습니다. 버전 3의 경우 구성 가능성, 안정성 및 사용자 경험에 중점을 두었습니다.
+Kubernetes 통합 버전 3에서 보고된 데이터는 버전 2 이후로 변경되지 않았습니다. 버전 3의 경우 구성 가능성, 안정성 및 사용자 경험에 중점을 두었습니다. [여기에서](/docs/release-notes/infrastructure-release-notes/kubernetes-integration-release-notes/) 통합에 대한 최신 릴리스 노트를 확인하세요.
Kubernetes 통합 버전 3( `appVersion` )은 `nri-bundle` 차트 `version` 4에 포함되어 있습니다.
@@ -18,12 +18,12 @@ Kubernetes 통합 버전 3에서 보고한 데이터는 버전 2 이후로 변
## 마이그레이션 가이드 [#migration-guide]
-이전 버전에서 가능한 한 쉽게 마이그레이션할 수 있도록 이전 newrelic-infrastructure 차트에서 지정할 수 있는 대부분의 옵션을 새 대응 항목으로 변환하는 호환성 계층을 개발했습니다. 이 호환성 계층은 일시적이며 향후 제거될 예정입니다. 따라서 이 가이드를 주의 깊게 읽고 사람의 감독 하에 구성을 마이그레이션하는 것이 좋습니다.
+이전 버전에서 최대한 쉽게 마이그레이션할 수 있도록 이전 `newrelic-infrastructure` 차트에서 구성 가능한 옵션 대부분을 새로운 옵션으로 변환하는 호환성 레이어를 개발했습니다. 이 호환성 레이어는 일시적이며 향후 제거될 예정입니다. 이 가이드를 주의 깊게 읽고 사람의 감독하에 구성을 마이그레이션하는 것이 좋습니다. [여기에서](https://github.com/newrelic/nri-kubernetes/tree/main/charts/newrelic-infrastructure#newrelic-infrastructure) 업데이트된 `newrelic-infrastructure` 차트에 대한 자세한 내용을 읽을 수 있습니다.
### KSM(Kube State Metrics) 구성 [#ksm-config]
- KSM 모니터링은 대부분의 구성에서 기본적으로 작동하므로 대부분의 사용자는 이 구성을 변경할 필요가 없습니다.
+ KSM 모니터링은 대부분의 구성에서 기본적으로 작동합니다. 대부분의 사용자는 이 구성을 변경할 필요가 없습니다.
* `disableKubeStateMetrics` `ksm.enabled` 으로 대체되었습니다. 기본값은 여전히 동일합니다(KSM 스크래핑 활성화됨).
@@ -49,7 +49,7 @@ ksm:
### 제어 평면 구성 [#controlplane-configuration]
-컨트롤 플레인 구성이 크게 변경되었습니다. 이전에 컨트롤 플레인 모니터링을 활성화한 경우 [컨트롤 플레인 모니터링 전용 페이지 구성](/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/configure-control-plane-monitoring) 을 살펴보는 것이 좋습니다.
+제어 평면 구성이 크게 변경되었습니다. 이전에 제어 플레인 모니터링을 활성화한 경우 [제어 플레인 모니터링 구성](/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/configure-control-plane-monitoring) 설명서를 살펴보는 것이 좋습니다.
다음 옵션은 위에 링크된 섹션에서 다루는 보다 포괄적인 구성으로 대체되었습니다.
@@ -60,15 +60,15 @@ ksm:
### 에이전트 구성 [#agent-configuration]
-이전에 `config` 에 지정된 에이전트 구성 파일이 `common.agentConfig` )로 이동되었습니다. 파일 형식은 변경되지 않았으며 여기에서 구성할 수 있는 전체 옵션을 찾을 수 [있습니다](/docs/infrastructure/install-infrastructure-agent/configuration/infrastructure-agent-configuration-settings/) .
+이전에 `config` 에 지정된 에이전트 구성 파일이 `common.agentConfig` 로 이동되었습니다. 파일 형식은 변경되지 않았으며 구성할 수 있는 전체 옵션 범위는 [여기에서](/docs/infrastructure/install-infrastructure-agent/configuration/infrastructure-agent-configuration-settings/) 확인할 수 있습니다.
-다음 에이전트 옵션은 이전에 `values.yml` 파일의 루트에서 "별칭 지정"되었으며 더 이상 사용할 수 없습니다.
+다음 에이전트 옵션은 이전에 `values.yml` 파일 루트에서 "별칭"이 지정되었으므로 **no longer available** \[더 이상 사용할 수 없습니다].
* `logFile` `common.agentConfig.log_file` 으로 대체되었습니다.
* `eventQueueDepth` `common.agentConfig.event_queue_depth` 으로 대체되었습니다.
-* `customAttributes` 형식이 yaml 개체로 변경되었습니다. 이전 형식인 수동으로 json으로 인코딩된 문자열(예: `{"team": "devops"}` )은 더 이상 사용되지 않습니다.
-* 이전에는 `customAttributes` 에 기본 `clusterName` 항목이 있었는데 제거할 경우 원치 않는 결과가 발생할 수 있습니다. 더 이상 그렇지 않습니다. 이제 사용자는 `customAttributes` 전체를 안전하게 재정의할 수 있습니다.
-* `discoveryCacheTTL` 이제 검색이 내장 캐시가 있는 kubernetes 정보 제공자를 사용하여 수행되기 때문에 가 완전히 제거되었습니다.
+* `customAttributes` 형식이 yaml 객체로 변경되었습니다. 이전 형식은 수동으로 JSON으로 인코딩된 문자열입니다. 예: `{"team": "devops"}` 은(는) 더 이상 사용되지 않습니다.
+* 이전에는 `customAttributes` 에 제거할 경우 원치 않는 결과가 발생할 수 있는 기본 `clusterName` 항목이 있었습니다. 더 이상 그렇지 않습니다. 이제 사용자는 `customAttributes` 전체를 안전하게 재정의할 수 있습니다.
+* `discoveryCacheTTL` 이제 캐시가 내장된 Kubernetes 정보를 사용하여 검색이 수행되므로 완전히 제거되었습니다.
### 통합 구성 [#integrations-configuration]
@@ -111,36 +111,37 @@ integrations:
exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250
```
-이 변경은 v2 이하에서 `nrk8s-kubelet` 구성요소(또는 이에 상응하는 것)가 `hostNetwork: true` 와 함께 실행되어 `nri-discovery-kubernetes` 가 `localhost` 및 일반 http를 사용하여 kubelet에 연결할 수 있기 때문에 필요합니다. 보안상의 이유로 더 이상 그렇지 않으므로 지금부터 두 플래그를 모두 지정해야 합니다.
+이 변경이 필요한 이유는 v2 이하에서는 `nrk8s-kubelet` 구성 요소(또는 이에 상응하는 구성 요소)가 `hostNetwork: true` 로 실행되어 `nri-discovery-kubernetes` `localhost` 및 일반 http를 사용하여 kubelet에 연결할 수 있기 때문입니다. 보안상의 이유로 더 이상 그렇지 않습니다. 따라서 지금부터 두 플래그를 모두 지정해야 합니다.
-Kubernetes에서 호스트 내 통합을 구성하는 방법에 대한 자세한 내용은 Kubernetes [에서 서비스 모니터링](/docs/kubernetes-pixie/kubernetes-integration/link-apps-services/monitor-services-running-kubernetes) 페이지를 확인하세요.
+Kubernetes에서 온호스트 통합을 구성하는 방법에 대한 자세한 내용은 [Kubernetes 설명서의 모니터 서비스를](/docs/kubernetes-pixie/kubernetes-integration/link-apps-services/monitor-services-running-kubernetes) 확인하세요.
### 기타 차트 값 [#misc-chart-values]
-통합 구성과 관련이 없지만 helm 차트에 대한 다음 기타 옵션도 변경되었습니다.
+통합 구성과 관련이 없지만 Helm 차트에 대한 다음 기타 옵션도 변경되었습니다.
* `runAsUser` 포드에 직접 템플릿화되고 더 많은 구성이 가능한 `securityContext` 으로 대체되었습니다.
+
* `resources` 이제 세 가지 다른 워크로드를 배포하므로 제거되었습니다. 각각에 대한 리소스는 다음에서 개별적으로 구성할 수 있습니다.
-* `ksm.resources`
-* `kubelet.resources`
-* `controlPlane.resources`
-* 마찬가지로 `tolerations` 은(는) 세 개로 분할되었으며 이전 항목은 더 이상 유효하지 않습니다.
-* `ksm.tolerations`
-* `kubelet.tolerations`
-* `controlPlane.tolerations`
+ * `ksm.resources`
+ * `kubelet.resources`
+ * `controlPlane.resources`
-* 세 가지 모두 기본값은 `NoSchedule` 에 대한 모든 값을 허용하고 `NoExecute`
+* `tolerations` 3개로 분할되어 이전 항목은 더 이상 유효하지 않습니다. 세 가지 모두 기본적으로 `NoSchedule` 및 `NoExecute` 의 모든 값을 허용합니다.
+ * `ksm.tolerations`
+ * `kubelet.tolerations`
+ * `controlPlane.tolerations`
* `image` 모든 하위 키는 현재 배포된 세 개의 이미지 각각에 대한 개별 섹션으로 대체되었습니다.
-* `images.forwarder.*` 인프라 에이전트 전달자를 구성합니다.
-* `images.agent.*` 인프라-에이전트 및 온-호스트 통합을 번들하는 이미지를 구성합니다.
-* `images.integration.*` k8s 데이터 스크래핑을 담당하는 이미지를 구성합니다.
+
+ * `images.forwarder.*` 인프라 에이전트 전달자를 구성합니다.
+ * `images.agent.*` 인프라-에이전트 및 온-호스트 통합을 번들하는 이미지를 구성합니다.
+ * `images.integration.*` k8s 데이터 스크래핑을 담당하는 이미지를 구성합니다.
### v2에서 업그레이드 [#upgrade-from-v2]
-Kubernetes `values-newrelic.yaml` 버전 2( [nri-bundle 차트](https://github.com/newrelic/helm-charts/tree/master/charts/nri-bundle) 버전 3.x에 포함됨)에서 업그레이드하려면 원하는 및 구성. 예를 들어 다음과 같은 명령을 사용하여 이전에 CLI에서 차트를 직접 설치한 경우:
+버전 2( [nri-bundle 차트](https://github.com/newrelic/helm-charts/tree/master/charts/nri-bundle) 버전 3.x에 포함됨)에서 Kubernetes 통합을 업그레이드하려면 원하는 대로 `values-newrelic.yaml` 파일을 생성하는 것이 좋습니다. 그리고 구성. 이전에 다음과 같은 명령을 사용하여 CLI에서 직접 차트를 설치한 경우:
```shell
helm install newrelic/nri-bundle \
@@ -175,7 +176,7 @@ logging:
enabled: true
```
-이 작업을 수행하고 [위의 섹션](#migration-guide) 에 따라 변경했을 수 있는 다른 설정을 적용한 후 다음 명령을 실행하여 업그레이드할 수 있습니다.
+이 작업을 수행하고 [위의 마이그레이션 가이드에](#migration-guide) 따라 변경했을 수 있는 다른 설정을 적용한 후 다음 명령을 실행하여 `nri-bundle` ) 업그레이드할 수 있습니다.
```shell
helm upgrade newrelic newrelic/nri-bundle \
diff --git a/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/data-governance.mdx b/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/data-governance.mdx
index 5f2ba88e7b3..d0b89f3dd4e 100644
--- a/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/data-governance.mdx
+++ b/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/data-governance.mdx
@@ -10,7 +10,7 @@ translationType: machine
### 스크래핑 간격 변경 [#scrape-interval]
-Kubernetes 통합 v3 이상에서는 클러스터에서 메트릭이 수집되는 간격을 변경할 수 있습니다. 이를 통해 데이터 해상도와 사용량 간의 균형을 선택할 수 있습니다. 최적의 경험을 위해 15초에서 30초 사이의 간격을 선택하는 것이 좋습니다.
+[New Relic Kubernetes 통합 v3](/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/changes-since-v3/) 이상에서는 클러스터에서 지표가 수집되는 간격을 변경할 수 있습니다. 이를 통해 데이터 해상도와 사용량 간의 균형을 선택할 수 있습니다. 최적의 경험을 위해 15-30초 사이의 간격을 선택하는 것이 좋습니다.
스크래핑 간격을 변경하려면 `newrelic-infrastructure` 섹션 아래의 `values-newrelic.yaml` 에 다음을 추가하세요.
@@ -27,11 +27,11 @@ global:
licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
cluster: _K8S_CLUSTER_NAME_
-# ... Other settings as shown above
+# ... Other settings
# Configuration for newrelic-infrastructure
newrelic-infrastructure:
- # ... Other settings as shown above
+ # ... Other settings
common:
config:
interval: 25s
@@ -43,7 +43,7 @@ newrelic-infrastructure:
### 네임스페이스 필터링 [#filter-namespace]
-Kubernetes 통합 v3 이상에서는 레이블을 지정하여 스크랩할 네임스페이스를 필터링할 수 있습니다.기본적으로 모든 네임스페이스는 스크랩됩니다.
+Kubernetes 통합 v3 이상에서는 라벨을 지정하여 스크랩되는 네임스페이스를 필터링할 수 있습니다. 모든 네임스페이스는 기본적으로 스크랩됩니다.
Kubernetes와 동일한 방식으로 `namespaceSelector` 을 사용합니다.레이블과 일치하는 네임스페이스만 포함하려면 `newrelic-infrastructure` 섹션 아래의 `values-newrelic.yaml` 에 다음을 추가하여 `namespaceSelector` 을 변경합니다.
@@ -62,11 +62,11 @@ global:
licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
cluster: _K8S_CLUSTER_NAME_
-# ... Other settings as shown above
+# ... Other settings
# Configuration for newrelic-infrastructure
newrelic-infrastructure:
- # ... Other settings as shown above
+ # ... Other settings
common:
config:
namespaceSelector:
@@ -89,18 +89,18 @@ common:
`matchExpressions` 아래의 표현식은 연결됩니다.
-이 예시에서 `newrelic.com/scrape` 레이블이 `false` }로 설정된 네임스페이스는 제외됩니다.
+이 예에서는 `newrelic.com/scrape` 레이블이 `false` 로 설정된 네임스페이스가 제외됩니다.
```yaml
global:
licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
cluster: _K8S_CLUSTER_NAME_
-# ... Other settings as shown above
+# ... Other settings
# Configuration for newrelic-infrastructure
newrelic-infrastructure:
- # ... Other settings as shown above
+ # ... Other settings
common:
config:
namespaceSelector:
@@ -108,13 +108,13 @@ newrelic-infrastructure:
- {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}
```
-[차트의 README 파일](https://github.com/newrelic/nri-kubernetes/tree/main/charts/newrelic-infrastructure) 에서 수정할 수 있는 설정의 전체 목록을 참조하십시오.
+[차트의 README 파일](https://github.com/newrelic/nri-kubernetes/tree/main/charts/newrelic-infrastructure) 에서 수정할 수 있는 전체 설정 목록을 확인하세요.
-#### 제외된 네임스페이스를 어떻게 알 수 있습니까? [#excluded-namespaces]
+#### 어떤 네임스페이스가 제외되는지 어떻게 알 수 있나요? [#excluded-namespaces]
클러스터 내의 모든 네임스페이스는 `K8sNamespace` 샘플 덕분에 나열됩니다.`nrFiltered` 속성은 네임스페이스와 관련된 데이터를 스크랩할지 여부를 결정합니다.
-이 쿼리를 사용하여 모니터링 중인 네임스페이스를 확인합니다.
+모니터링되고 있는 네임스페이스를 찾으려면 다음 쿼리를 사용하세요.
```sql
FROM K8sNamespaceSample SELECT displayName, nrFiltered WHERE clusterName = SINCE 2 MINUTES AGO
diff --git a/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/install-fargate-integration.mdx b/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/install-fargate-integration.mdx
index 7ae987cb650..08246329d44 100644
--- a/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/install-fargate-integration.mdx
+++ b/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/install-fargate-integration.mdx
@@ -4,6 +4,7 @@ tags:
- Integrations
- Kubernetes integration
- Installation
+ - Fargate
metaDescription: How to install the Infrastructure Operator in EKS Fargate.
translationType: machine
---
@@ -82,6 +83,7 @@ EKS Fargate 클러스터에 New Relic 전체 관찰 가능성을 설치하기
- "nodes/proxy"
- "pods"
- "services"
+ - "namespaces"
verbs: ["get", "list"]
- nonResourceURLs: ["/metrics"]
verbs: ["get"]
@@ -91,6 +93,10 @@ EKS Fargate 클러스터에 New Relic 전체 관찰 가능성을 설치하기
사이드카가 주입되고 따라서 운영자가 설치되기 전에 배포된 포드에서 메트릭을 얻으려면 영향을 받는 배포의 롤아웃(다시 시작)을 수동으로 수행해야 합니다. 이렇게 하면 포드가 생성될 때 운영자가 모니터링 사이드카를 삽입할 수 있습니다. New Relic은 예기치 않은 서비스 중단 및 리소스 사용량 급증을 방지하기 위해 이 작업을 자동으로 수행하지 않도록 선택했습니다.
+
+ `newrelic` 네임스페이스(또는 설치를 위해 선택한 네임스페이스)를 선언하는 선택기를 사용하여 Fargate 프로필을 생성해야 합니다.
+
+
주입 워크플로는 다음과 같습니다.
헤더로.
+먼저 New Relic과 함께 [OpenTelemetry Collector 구성 YAML 파일](https://opentelemetry.io/docs/collector/configuration/) 에 OTLP 내보내기를 추가합니다. 헤더로.
```yaml
exporters:
@@ -167,7 +167,7 @@ exporters:
### 2단계: 배치 프로세서 구성 [#batch]
-일괄 처리 프로세서는 범위, 메트릭 또는 로그를 수락하고 일괄 처리에 배치하여 데이터를 더 쉽게 압축하고 수집기에서 나가는 요청 수를 줄입니다.
+일괄 프로세서는 범위, 측정항목 또는 로그를 받아 일괄 처리하므로 데이터를 더 쉽게 압축하고 수집기에서 나가는 요청 수를 줄일 수 있습니다.
```
processors:
@@ -195,7 +195,7 @@ Detectors: [ gke, gce ]
### 4단계: Kubernetes 속성 프로세서 구성(일반) [#attributes-general]
-에이전트로 실행되는 OpenTelemetry Collector의 일부로 `k8sattributes` 프로세서를 실행하면 원격 측정 데이터를 OpenTelemetry Collector 에이전트로 전송하는 포드의 IP 주소를 감지하고 이를 사용하여 포드 메타데이터를 추출합니다. 다음은 프로세서 섹션만 있는 기본 Kubernetes 매니페스트 예제입니다. OpenTelemetry Collector를 `DaemonSet`로 배포하려면 이 [포괄적인 매니페스트 예제를](https://github.com/newrelic-forks/microservices-demo/tree/main/src/otel-collector-agent)읽으십시오.
+에이전트로 실행되는 OpenTelemetry Collector의 일부로 `k8sattributes` 프로세서를 실행하면 OpenTelemetry Collector 에이전트에 원격 측정 데이터를 보내는 Pod의 IP 주소를 감지하고 이를 사용하여 Pod 메타데이터를 추출합니다. 다음은 프로세서 섹션만 있는 기본 Kubernetes 매니페스트 예시입니다. OpenTelemetry Collector를 `DaemonSet` 로 배포하려면 이 [포괄적인 매니페스트 예제를](https://github.com/newrelic-forks/microservices-demo/tree/main/src/otel-collector-agent) 읽어보세요.
```yaml
processors:
@@ -220,7 +220,7 @@ processors:
### 5단계: Kubernetes 속성 프로세서(RBAC) 구성 [#rbac]
-RBAC(역할 기반 액세스 제어)에 대한 구성을 추가해야 합니다. `k8sattributes` 프로세서에는 구성된 필터에 포함된 포드 및 네임스페이스 리소스에 대한 `get` , `watch` 및 `list` 권한이 필요합니다. 클러스터의 모든 포드 및 네임스페이스에 필요한 권한을 `ServiceAccount` 에 부여하도록 `ClusterRole` 에 대한 역할 기반 액세스 제어(RBAC)를 구성하는 방법에 대한 이 [예시](https://github.com/newrelic-forks/microservices-demo/blob/main/otel-kubernetes-manifests/otel-collector-agent.yaml#L43-L69) 를 참조하세요.
+RBAC(역할 기반 액세스 제어)에 대한 구성을 추가해야 합니다. `k8sattributes` 프로세서에는 구성된 필터에 포함된 포드 및 네임스페이스 리소스에 대한 `get`, `watch` 및 `list` 권한이 필요합니다. 클러스터의 모든 Pod와 네임스페이스에 대해 필요한 권한을 `ServiceAccount` 에 부여하기 위해 `ClusterRole` 에 대한 역할 기반 액세스 제어(RBAC)를 구성하는 방법에 대한 이 [예를](https://github.com/newrelic-forks/microservices-demo/blob/main/otel-kubernetes-manifests/otel-collector-agent.yaml#L43-L69) 참조하세요.
### 6단계: Kubernetes 속성 프로세서 구성(검색 필터) [#discovery-filter]
@@ -261,4 +261,6 @@ OpenTelemetry 데이터를 Kubernetes 데이터와 성공적으로 연결했다
## 다음은 뭐지? [#next]
-이제 OpenTelemetry 계측 앱을 Kubernetes와 연결했으므로 [모범 사례](/docs/integrations/open-source-telemetry-integrations/opentelemetry/opentelemetry-concepts/) 가이드에서 OpenTelemetry 및 New Relic 사용을 개선하기 위한 팁을 확인하세요.
\ No newline at end of file
+이제 OpenTelemetry 계측 앱을 Kubernetes와 연결했으므로 [모범 사례](/docs/integrations/open-source-telemetry-integrations/opentelemetry/opentelemetry-concepts/) 가이드에서 OpenTelemetry 및 New Relic 사용을 개선하기 위한 팁을 확인하세요.
+
+위에 제공된 단계에 대한 자세한 내용은 이 블로그 게시물 [인 OpenTelemetry 추적, 메트릭 및 로그를 Kubernetes 성능 데이터와 상호 연관시키는 방법을](https://newrelic.com/blog/how-to-relic/k8s-with-otel) 확인할 수도 있습니다.
\ No newline at end of file
diff --git a/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/troubleshooting/helm-configurations-not-applied.mdx b/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/troubleshooting/helm-configurations-not-applied.mdx
index 133ff7cbc41..461eac9b915 100644
--- a/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/troubleshooting/helm-configurations-not-applied.mdx
+++ b/src/i18n/content/kr/docs/kubernetes-pixie/kubernetes-integration/troubleshooting/helm-configurations-not-applied.mdx
@@ -10,11 +10,11 @@ translationType: machine
## 문제 [#problem]
-`nri-bundle` 에 대한 helm과 New Relic의 Kubernetes 통합을 위한 [설치 절차를](/docs/kubernetes-monitoring-integration#install) 완료했지만 `values.yaml` 파일의 값이 존중되지 않습니다.
+`nri-bundle` 에 대한 Helm과 New Relic의 Kubernetes 통합을 위한 [설치 절차를](/docs/kubernetes-monitoring-integration#install) 완료했지만 Helm 템플릿이 `values.yaml` 의 일부 [전역 값을](https://github.com/newrelic/helm-charts/tree/master/charts/nri-bundle#values) 준수하지 않습니다.
-### 해결책 [#solution]
+## 해결책 [#solution]
-일부 [전역 값은](https://github.com/newrelic/helm-charts/tree/master/charts/nri-bundle#values) helm 템플릿에서 준수하지 않는 것으로 확인되었으므로 적절한 차트에서 전역 값을 준수하지 않는 경우 차트를 직접 지정하십시오. 이 해결 방법은 문제를 해결해야 합니다.
+아래 예와 같이 차트를 직접 지정합니다.
```yml
global:
@@ -23,9 +23,9 @@ global:
tolerations: # We are interested in setting this toleration for our pods, but the global value is not respected for some reason
- key: role
operator: Exists
- effect: NoSchedul
+ effect: NoSchedule
-# Directly specifying the chart and the desired pod toleration will always be respected
+# Directly specify the chart, and the desired pod toleration will always be respected
newrelic-infrastructure:
kubelet:
tolerations:
diff --git a/src/i18n/content/kr/docs/network-performance-monitoring/advanced/advanced-config.mdx b/src/i18n/content/kr/docs/network-performance-monitoring/advanced/advanced-config.mdx
index 4c2a6a6687e..7ac14c58338 100644
--- a/src/i18n/content/kr/docs/network-performance-monitoring/advanced/advanced-config.mdx
+++ b/src/i18n/content/kr/docs/network-performance-monitoring/advanced/advanced-config.mdx
@@ -133,7 +133,6 @@ devices:
ext_only: true
meraki_config:
api_key: APIKEY123ABC
- monitor_clients: true
monitor_devices: true
monitor_org_changes: true
monitor_uplinks: true
@@ -1299,34 +1298,6 @@ global:
>
[Meraki 대시보드 API](https://developer.cisco.com/meraki/api-latest/) 통합은 Meraki 환경의 상태와 관련된 다양한 측정항목을 가져옵니다. 다양한 구성 옵션을 조합하면 필요에 따라 다양한 모니터링 시나리오를 설정할 수 있습니다.
- * `meraki_config.monitor_clients: true`: [Get Network Clients](https://developer.cisco.com/meraki/api-latest/get-network-clients/) 엔드포인트를 사용하여 모든 대상 네트워크를 반복하고 클라이언트 데이터를 반환합니다.
-
-
- 대규모 환경에서 이 API 호출에는 Meraki Dashboard API에 대한 시간 초과로 인해 측정항목이 누락되는 알려진 문제가 있습니다.
-
-
- 네트워크 클라이언트 원격 측정을 찾기 위한 NRQL:
-
- ```sql
- FROM Metric SELECT
- latest(status) AS 'Current Client Status',
- max(kentik.meraki.clients.RecvTotal) AS 'Total Received Bytes',
- max(kentik.meraki.clients.SentTotal) AS 'Total Sent Bytes'
- FACET
- network AS 'Network Name',
- client_id AS 'Client ID',
- client_mac_addr AS 'Client MAC',
- description AS 'Client Description',
- vlan AS 'Client VLAN',
- user AS 'Client User',
- manufacturer AS 'Client Manufacturer',
- device_type AS 'Client Type',
- recent_device_name AS 'Latest Device'
- WHERE instrumentation.name = 'meraki.clients'
- ```
-
-
-
* `meraki_config.monitor_devices: true && meraki_config.preferences.device_status_only: true`: [조직 장치 상태 가져오기](https://developer.cisco.com/meraki/api-latest/get-organization-devices-statuses/) 엔드포인트를 사용하여 조직의 모든 Meraki 장치 상태를 나열합니다.
장치 상태 원격 분석을 찾기 위한 NRQL:
@@ -1470,22 +1441,6 @@ global:
-
-
- meraki_config.monitor_clients
-
-
-
-
-
- 사실 | 거짓(기본값: 거짓)
-
-
-
- 네트워크별 클라이언트 상태 및 성능을 모니터링합니다. _(시간 초과 문제로 인해 대규모 환경에는 권장되지 않음)_
-
- 폴링을 상태 정보로만 제한하기 위해 `monitor_devices` 과 함께 사용됩니다. _(이는 대규모 조직에서 시간 초과 문제를 방지하는 데 유용합니다.)_
+ 폴링을 상태 정보로만 제한하기 위해 `monitor_devices: true` 사용할 때 _필요합니다_ . **(타임아웃 문제를 방지하기 위해 사용됩니다.)**
+ 명령줄 플래그를 스크립트에 전달하려면 `-run -script` 과 함께 사용하세요.
+
+
+
`-v`
diff --git a/src/i18n/content/kr/docs/new-relic-solutions/solve-common-issues/diagnostics-cli-nrdiag/run-diagnostics-cli-nrdiag.mdx b/src/i18n/content/kr/docs/new-relic-solutions/solve-common-issues/diagnostics-cli-nrdiag/run-diagnostics-cli-nrdiag.mdx
index e8ef4379360..21447539ad8 100644
--- a/src/i18n/content/kr/docs/new-relic-solutions/solve-common-issues/diagnostics-cli-nrdiag/run-diagnostics-cli-nrdiag.mdx
+++ b/src/i18n/content/kr/docs/new-relic-solutions/solve-common-issues/diagnostics-cli-nrdiag/run-diagnostics-cli-nrdiag.mdx
@@ -234,9 +234,99 @@ PowerShell에서 실행하려면 `cmd` 시작 부분에 `./` 를 추가합니다
* ARM64 시스템의 경우:
```
- nrdiag_arm64 -suites SUITE NAMES
+ nrdiag_arm64.exe -suites SUITE NAMES
```
+## 스크립트 [#scripts]
+
+스크립트는 작업으로 수집되지 않은 정보에 대한 추가 데이터 소스를 제공합니다. 사용 가능한 스크립트 카탈로그는 [Diagnostic CLI의 github 저장소](https://github.com/newrelic/newrelic-diagnostics-cli/tree/main/scriptcatalog) 에서 찾을 수 있습니다.
+
+### 스크립트 출력
+
+스크립트 출력은 화면에 인쇄되고 스크립트 이름(예: `name-of-script.out`)을 기반으로 파일에 저장됩니다. 이는 `-output-path` 에서 지정한 디렉토리에 저장되며 기본값은 현재 디렉토리입니다.
+
+스크립트는 현재 작업 디렉터리나 `-output-path` 에서 지정한 디렉터리로 파일을 출력할 수도 있습니다. 모든 출력 파일은 `ScriptOutput/` 디렉터리의 결과 zip에 포함됩니다.
+
+### 스크립트 결과
+
+스크립트 실행 결과는 다음 스키마를 사용하여 `nrdiag-output.json` 파일에서 찾을 수 있습니다.
+
+```json
+"Script": {
+ "Name": "example",
+ "Description": "Example Description",
+ "Output": "example output",
+ "OutputFiles": [
+ "/path/to/example.out",
+ "/path/to/another-file.out"
+ ],
+ "OutputTruncated": false
+}
+```
+
+`Output` 필드에는 stdout 출력이 포함되어 있습니다. 20000자를 초과하면 잘리고 `OutputTruncated` 필드가 `true` 로 설정됩니다. 잘리더라도 zip 파일의 `ScriptOutput/` 디렉터리에서 전체 출력을 계속 사용할 수 있습니다.
+
+스크립트가 생성한 파일 목록은 `Outputfiles` 필드에서 찾을 수 있습니다.
+
+### 스크립트 나열, 보기 및 실행 [#list-view-run-script]
+
+
+
+ 실행할 수 있는 스크립트 목록을 보려면 `-list-scripts` 사용하세요.
+
+ ```
+ ./nrdiag -list-scripts
+ ```
+
+
+
+ 스크립트를 실행하지 않고 보려면:
+
+ ```
+ ./nrdiag -script SCRIPT_NAME
+ ```
+
+
+
+ 스크립트를 실행하려면:
+
+ ```
+ ./nrdiag -script SCRIPT_NAME -run
+ ```
+
+
+
+ 인수를 사용하여 스크립트를 실행하려면 다음을 수행하십시오.
+
+ ```
+ ./nrdiag -script SCRIPT_NAME -run -script-flags "-foo bar"
+ ```
+
+
+
+ 스크립트와 제품군을 동시에 실행하려면 다음 안내를 따르세요.
+
+ ```
+ ./nrdiag -script SCRIPT_NAME -run -s SUITE NAMES"
+ ```
+
+
+
## zip에 추가 파일 포함 [#include-additional-files]
지원팀과 공유하고 싶은 추가 파일이 있는 경우 `-include` 명령줄 플래그를 사용하여 `nrdiag-output.zip` 파일에 포함할 수 있습니다. 이것은 단일 파일 또는 디렉토리와 함께 사용할 수 있습니다. 디렉토리가 제공되면 모든 하위 디렉토리가 포함됩니다. 포함된 파일의 총 크기 제한은 4GB입니다.
@@ -264,7 +354,7 @@ PowerShell에서 실행하려면 `cmd` 시작 부분에 `./` 를 추가합니다
* 32비트 시스템의 경우:
```
- nrdiag -include Path\To\File -attach
+ nrdiag.exe -include Path\To\File -attach
```
* 64비트 시스템의 경우:
@@ -336,7 +426,7 @@ Diagnostics CLI가 실행될 때 결과를 New Relic 계정에 자동으로 업
또는
```
- nrdiag -api-key ${API_KEY}
+ nrdiag.exe -api-key ${API_KEY}
```
* 64비트 시스템의 경우:
@@ -348,7 +438,7 @@ Diagnostics CLI가 실행될 때 결과를 New Relic 계정에 자동으로 업
또는
```
- nrdiag_x64 -api-key ${API_KEY}
+ nrdiag_x64.exe -api-key ${API_KEY}
```
* ARM64 시스템의 경우:
@@ -360,7 +450,7 @@ Diagnostics CLI가 실행될 때 결과를 New Relic 계정에 자동으로 업
또는
```
- nrdiag_arm64 -api-key ${API_KEY}
+ nrdiag_arm64.exe -api-key ${API_KEY}
```
diff --git a/src/i18n/content/kr/docs/new-relic-solutions/tutorials/build-react-hooks-app.mdx b/src/i18n/content/kr/docs/new-relic-solutions/tutorials/build-react-hooks-app.mdx
new file mode 100644
index 00000000000..e1dc08572f4
--- /dev/null
+++ b/src/i18n/content/kr/docs/new-relic-solutions/tutorials/build-react-hooks-app.mdx
@@ -0,0 +1,377 @@
+---
+title: React 후크로 New Relic 앱 빌드
+tags:
+ - New Relic solutions
+ - Build with New Relic
+metaDescription: Build a simple New Relic app with React hooks
+translationType: machine
+---
+
+import autoIncrement from 'images/react-hooks-screenshot-auto-increment.webp'
+
+import buttonIncrement from 'images/react-hooks-screenshot-button-increment.webp'
+
+import staticBillboard from 'images/react-hooks-screenshot-static-billboard-local.webp'
+
+
+
+`nr1` CLI의 버전 2.49.1부터 [React 후크를](https://reactjs.org/docs/hooks-intro.html)사용하여 New Relic 애플리케이션 및 맞춤 시각화를 빌드할 수 있습니다. 이 가이드는 작동 중인 React 후크의 Nerdlet 예제를 제공합니다!
+
+## 시작하기 전에
+
+Nerdpacks를 개발하려면 New Relic 계정과 New Relic CLI `nr1`가 필요합니다.
+
+아직 하지 않은 경우:
+
+* New Relic 계정에[가입하세요](https://newrelic.com/signup/)
+* [Node.js](https://nodejs.org/en/download/)설치
+* [CLI 빠른 시작](https://one.newrelic.com/launcher/developer-center.launcher?pane=eyJuZXJkbGV0SWQiOiJkZXZlbG9wZXItY2VudGVyLmRldmVsb3Blci1jZW50ZXIifQ==)완료
+
+이제 `my-awesome-nerdpack` 라는 Nerdpack이 있습니다. 이 Nerdpack에는 Nerdlet과 이름을 지정한 실행기가 있습니다(이 가이드에서는 기본 실행기 이름인 "launcher"와 Nerdlet 이름인 "home"을 사용함). 이 가이드 전체에서 이 Nerdpack을 사용합니다.
+
+마지막으로 `nr1` 이(가) 최신 상태인지 확인하세요. 이 가이드에는 최소 버전 2.49.1이 필요합니다.
+
+```sh
+nr1 update
+nr1 version
+[output] @datanerd/nr1/{purple}2.49.1{normal} darwin-x64 node-v14.15.1
+```
+
+
+ VSCode를 사용하는 경우 앱을 빌드하는 데 사용할 수 있는 [확장](https://marketplace.visualstudio.com/items?itemName=new-relic.nr1) 및 [확장 팩이](https://marketplace.visualstudio.com/items?itemName=new-relic.new-relic-extension-pack) 있습니다.
+
+
+```jsx fileName=index.js
+import React from 'react';
+
+
+export default class HomeNerdlet extends React.Component {
+ render() {
+ return
Hello, home Nerdlet!
;
+ }
+}
+```
+
+## 로컬에서 애플리케이션 업데이트 및 제공
+
+`nr1` 사용하면 Nerdpack의 로컬 빌드를 New Relic에 제공할 수 있습니다. 이를 통해 애플리케이션을 게시하기 전에 프로덕션과 유사한 환경에서 애플리케이션을 개발할 수 있습니다.
+
+코드를 변경하기 전에 Nerdpack의 디렉토리 구조를 숙지하십시오.
+
+```txt lineHighlight=3-10,12
+my-awesome-nerdpack/
+├───README.md
+├───launchers/
+│ └───launcher/
+│ └───nr1.json
+├───nerdlets/
+│ └───home
+│ ├───index.js
+│ ├───nr1.json
+│ └───styles.scss
+├───node_modules/
+├───nr1.json
+├───package-lock.json
+└───package.json
+```
+
+_런처_ 및 _nerdlet_ 디렉토리에는 애플리케이션의 로직이 포함되어 있습니다. 대부분의 코드를 업데이트하는 곳은 이 디렉토리입니다. Nerdpack 전체의 _nr1.json_ 파일에는 Nerdpack, Nerdlet 및 런처에 대한 메타데이터가 들어 있습니다.
+
+
+ Nerdpack 파일 구조에 대해 자세히 알아보려면 [설명서를](https://developer.newrelic.com/explore-docs/nerdpack-file-structure/) 읽으십시오.
+
+
+
+
+ _my-awesome-nerdpack/nerdlets/home/index.js_에서 _HomeNerdlet_ 클래스를 함수로 변경합니다.
+
+ ```jsx fileName=index.js
+ import React from 'react';
+
+ function HomeNerdlet () {
+ return
Hello, home Nerdlet!
;
+ }
+
+ export default HomeNerdlet
+ ```
+
+
+
+ 다음으로 헤더 대신 빌보드 차트를 반환합니다.
+
+ ```jsx fileName=index.js
+ import React from 'react';
+ import { BillboardChart} from 'nr1'
+
+ function HomeNerdlet () {
+
+ const clickCount = {
+ metadata: {
+ id: '1',
+ name: 'Count',
+ viz: 'main',
+ },
+ data: [
+ { "y": 10 }
+ ]
+ }
+ return
+ }
+
+ export default HomeNerdlet
+ ```
+
+
+
+ 지금은 빌보드 차트에 정적 값을 표시하고 있지만 이후 단계에서는 함수의 로컬 상태를 사용하여 동적 값을 제공합니다.
+
+
+
+ 아직 제공하지 않은 경우 Nerdpack의 루트 디렉터리에서 애플리케이션을 제공합니다.
+
+ ```bash
+ nr1 nerdpack:serve
+ [output] Found and loaded {success}2 {plain}nr1.json files on MyAwesomeNerdpack ({purple}aad7ebb6-8901-43d0-a681-0719b2c60a11{plain}) Nerdpack.
+ [output]
+ [output] {purple}Nerdpack:
+ [output] {success}✔ MyAwesomeNerdpack {plain}({purple}aad7ebb6-8901-43d0-a681-0719b2c60a11{plain}) {blue}nr1.json
+ [output]
+ [output] {purple}Launchers:
+ [output] {success}✔ launcher {blue}launchers/launcher/nr1.json
+ [output]
+ [output] {purple}Nerdlets:
+ [output] {success}✔ home {blue}nerdlets/home/nr1.json
+ [output]
+ [output] There is no certificate created yet.
+ [output] {success}✔ {plain}New certificate created.
+ [output]
+ [output] Webpack bundle analyzer is enabled (you need to wait for the first build to finish)
+ [output] └ You can head to {blue}http://127.0.0.1:27888
+ [output]
+ [output] {blue}NOTE: {plain}To verify how your assets will look in production, you need to
+ [output] add "--mode=prod" when starting the development server.
+ [output]
+ [output] 🛠 Built artifact files for:ex.js...
+ [output] ⁎ {purple}aad7ebb6-8901-43d0-a681-0719b2c60a11--home {plain}built {success}✔
+ [output]
+ [output] {success}✔ {plain}Nerdpack built successfully!
+ [output] {yellow}★ {plain}Starting as orchestrator...
+ [output]
+ [output] {success}✔ {plain}Server ready! Test it at: {blue}https://one.newrelic.com/?nerdpacks=local
+ [output] {blue}↩ {plain}Server will reload automatically if you modify any file!
+ [output]
+ [output] {blue}ℹ {plain}Additionally, you can test the following artifacts at:
+ [output]
+ [output] {purple}Launchers:
+ [output] ⁎ {success}launcher {blue}https://onenr.io/0z7wkEkMnjL
+ [output] {blue}ℹ {plain}You can use "npm start -- --mode=prod" to run the development server in prod mode.
+ ```
+
+
+
+ 출력 하단의 URL을 사용하여 런처를 엽니다.
+
+ ```bash
+ [output] {purple}Launchers:
+ [output] * {success}launcher {blue}https://onenr.io/0z7wkEkMnjL
+ [output] {blue}ℹ {plain}You can use "npm start -- --mode=prod" to run the development server in prod mode.
+ ```
+
+
+
+ 여기에서 숫자 "10"을 표시하는 빌보드 차트와 함께 Nerdlet을 볼 수 있습니다.
+
+
+
+
+
+파일을 수정할 때 Nerdlet이 자동으로 다시 로드되므로 서버를 실행 상태로 둡니다.
+
+## Nerdlet에서 `useState()` 후크 사용
+
+이전에는 빌보드 차트에 정적 값을 사용했습니다. 이제 함수의 로컬 상태를 사용하여 동적 값을 저장하고 해당 값을 차트에 표시합니다.
+
+
+
+ _my-awesome-nerdpack/nerdlets/home/index.js_에서 함수 구성요소에서 `useState()` 호출합니다.
+
+ ```jsx fileName=index.js
+ import React, {useState} from 'react';
+ import { BillboardChart} from 'nr1'
+
+ function HomeNerdlet () {
+ const [count, setCount] = useState(0);
+
+ const clickCount = {
+ metadata: {
+ id: '1',
+ name: 'Count',
+ viz: 'main',
+ },
+ data: [
+ { "y": 10 }
+ ]
+ }
+ return
+ }
+
+ export default HomeNerdlet
+ ```
+
+
+
+ 여기에서 `useState()`호출합니다. 이 후크는 배열에서 캡처하는 두 값을 반환합니다.
+
+ * `count`: 로컬 상태의 현재 값입니다. 기본값은 `useState()`에 전달한 인수인 0입니다.
+ * `setCount`: 업데이트에 사용하는 기능 `count`
+
+
+
+ `count`사용하도록 빌보드 차트 데이터를 변경합니다.
+
+ ```jsx fileName=index.js
+ import React, {useState} from 'react';
+ import { BillboardChart} from 'nr1'
+
+ function HomeNerdlet () {
+ const [count, setCount] = useState(0);
+
+ const clickCount = {
+ metadata: {
+ id: '1',
+ name: 'Count',
+ viz: 'main',
+ },
+ data: [
+ { "y": count }
+ ]
+ }
+ return
+ }
+
+ export default HomeNerdlet
+ ```
+
+
+
+ 현재 상태를 업데이트하지 않기 때문에 count 값은 렌더링할 때마다 `0` 가 됩니다. 그렇게 할 방법이 필요합니다.
+
+
+
+ 차트와 함께 버튼을 렌더링하여 `count`를 증가시킵니다.
+
+ ```jsx fileName=index.js
+ import React, {useState} from 'react';
+ import { BillboardChart} from 'nr1'
+
+ function HomeNerdlet () {
+ const [count, setCount] = useState(0);
+
+ const clickCount = {
+ metadata: {
+ id: '1',
+ name: 'Count',
+ viz: 'main',
+ },
+ data: [
+ { "y": count }
+ ]
+ }
+ return (
+
+
+
+
+ );
+ }
+
+ export default HomeNerdlet
+ ```
+
+
+
+ 여기서 클릭할 때마다 카운트를 1씩 증가시키는 버튼을 Nerdlet에 추가했습니다.
+
+
+
+ Nerdlet을 실행하는 브라우저로 이동하여 변경 사항을 확인하십시오.
+
+
+
+ 버튼을 몇 번 클릭하면 카운트가 증가합니다.
+
+
+
+## Nerdlet에서 `useEffect()` 후크 사용
+
+Nerdlet에는 이제 빌보드 차트와 버튼이 있습니다. 차트에는 버튼을 클릭한 횟수가 표시됩니다. `useEffect()` ) 사용하여 `count`자동으로 증가시킵니다.
+
+
+
+ _my-awesome-nerdpack/nerdlets/home/index.js_에서 효과를 만듭니다.
+
+ ```jsx fileName=index.js
+ import React, {useState, useEffect} from 'react';
+ import { BillboardChart} from 'nr1'
+
+ function HomeNerdlet () {
+ const [count, setCount] = useState(0);
+
+ useEffect(() => {
+ setTimeout(() => {
+ setCount(() => count + 1);
+ }, 1000);
+ });
+
+ const clickCount = {
+ metadata: {
+ id: '1',
+ name: 'Count',
+ viz: 'main',
+ },
+ data: [
+ { "y": count }
+ ]
+ }
+ return (
+
+
+
+ );
+ }
+
+ export default HomeNerdlet
+ ```
+
+
+
+ `useEffect()` 1초마다 `count` 값을 자동으로 증가시킵니다. 카운트를 자동화했으므로 증분 버튼도 제거했습니다.
+
+
+
+ 업데이트를 보려면 브라우저로 이동하십시오.
+
+
+
+
+
+## 요약
+
+이 가이드에서는 다음 방법을 배웠습니다.
+
+* 로컬 New Relic Nerdpack 만들기
+* Nerdpack에서 후크 사용
\ No newline at end of file
diff --git a/src/i18n/content/kr/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries.mdx b/src/i18n/content/kr/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries.mdx
index b563310319f..73b99942f06 100644
--- a/src/i18n/content/kr/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries.mdx
+++ b/src/i18n/content/kr/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries.mdx
@@ -1,41 +1,35 @@
---
-title: NRQL 쿼리 제한
+title: NRQL 쿼리 속도 제한
metaDescription: 'An explanation of rate limits for NRQL, the New Relic query language'
translationType: machine
---
import queriesnrqlEventCountinQueryBuilder from 'images/queries-nrql_screenshot-crop_event-count-in-query-builder.webp'
-New Relic 쿼리 언어인 NRQL에는 모든 사용자에게 높은 수준의 가용성과 안정성을 보장하기 위해 속도 제한이 있습니다.
+New Relic 쿼리 언어인 NRQL에는 고객의 쿼리 속도가 다른 고객의 경험에 영향을 미치지 않도록 각 New Relic 조직마다 속도 제한이 있습니다.
-## 쿼리 제한 위반 이해 [#limit-breaches]
+## 쿼리 한도 초과 [#limit-breaches]
쿼리 관련 제한에 도달했는지 확인하려면 [Limits UI](/docs/data-apis/manage-data/view-system-limits/) 를 사용하세요.
-속도 제한은 거의 발생하지 않습니다. 쿼리 제한이 거의 발생하지 않도록 하기 위해 따라야 할 몇 가지 지침은 다음과 같습니다.
+NRQL 쿼리에 제한이 거의 발생하지 않습니다. 쿼리 제한이 발생하지 않도록 따라야 할 몇 가지 지침은 다음과 같습니다.
* 동시에 실행되는 복잡한 쿼리(예: `FACET` 또는 `TIMESERIES` 절이 있는 쿼리 또는 백만 개 이상의 이벤트 쿼리) 수를 제한합니다.
* 특히 복잡한 쿼리가 포함된 경우 장기간에 걸쳐 동시에 실행되는 쿼리 수를 최대 5개로 제한합니다.
## NRQL 쿼리 제한 [#query-limits]
-몇 가지 다른 NRQL 쿼리 제한이 있습니다.
+다음에는 제한이 있습니다.
-* 주어진 시간 범위에서 계정이 만들 수 있는 쿼리 수
-* 주어진 시간 범위에서 계정이 쿼리(검사)할 수 있는 데이터 포인트의 수
-* 오류로 간주되어 중지되기 전에 쿼리를 실행할 수 있는 시간
+* 특정 시간 범위에서 쿼리할 수 있는 데이터 포인트 수
+* 오류가 발생하여 중지되기 전에 쿼리를 실행할 수 있는 기간
+* 특정 기간 동안 수행할 수 있는 쿼리 수
-이러한 제한은 쿼리 빌더를 사용하는 쿼리, 사용자 지정 차트 및 대시보드에 사용되는 쿼리, NerdGraph API로 수행되는 NRQL 쿼리와 같이 고객이 시작한 NRQL 쿼리에만 적용됩니다. 이러한 제한은 사전 구축된 "즉시 사용 가능한" New Relic 차트 및 대시보드에 사용되는 쿼리에는 적용되지 않습니다.
+다음으로 이러한 한도에 대해 자세히 알아보겠습니다.
-### 쿼리 수 제한 [#query-count-limits]
+## 검사된 데이터 포인트에 대한 제한 [#inspected-count-limits]
-NRQL 쿼리에 대한 제한은 계정당 분당 3,000개 쿼리입니다. 이 제한을 초과하면 분당 전송된 쿼리 수가 더 이상 제한을 초과하지 않을 때까지 쿼리가 거부될 수 있습니다.
-
-이 제한은 NRQL 쿼리 API 요청에만 적용되며 쿼리 빌더, New Relic UI 또는 사용자 지정 대시보드에서 실행되는 쿼리에는 적용되지 않습니다.New Relic UI, 쿼리 빌더 또는 고객 대시보드에서 실행되는 이 쿼리 범주에 대한 리소스 소비 비율을 제어하는 제한은 검사된 수 제한일 뿐입니다.
-
-### 검사되는 데이터 포인트 수에 대한 제한 [#inspected-count-limits]
-
-NRQL 쿼리를 실행하면 아래와 같이 검사된 데이터 포인트 수가 표시됩니다.
+고객 주도 쿼리 또는 UI 페이지 로드로 인해 NRQL 쿼리가 실행되면 해당 쿼리는 NRDB 데이터베이스의 특정 수의 데이터 포인트를 검사합니다. 예를 들어 NRQL 쿼리를 실행하면 왼쪽 하단에 표시된 것처럼 검사된 데이터 포인트 수가 표시됩니다.
-이 컨텍스트에서 "이벤트"라는 용어는 쿼리에서 검사되는 모든 [NRQL 사용 가능한 데이터 포인트](/docs/query-data/nrql-new-relic-query-language/getting-started/introduction-nrql#what-you-can-query) 를 나타내는 일반적인 의미로 사용됩니다.
+
+ 이 컨텍스트에서 `events` 쿼리로 검사된 모든 [NRQL 저장 데이터 포인트를](/docs/query-data/nrql-new-relic-query-language/getting-started/introduction-nrql#what-you-can-query) 나타냅니다.
+
-모든 New Relic 계정에는 주어진 시간 범위에서 검사할 수 있는 총 데이터 포인트 수에 제한이 있습니다. 이러한 제한은 보유한 [데이터 옵션](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-prices) 에 따라 다릅니다.
+검사된 개수 제한은 특정 시간 범위에서 쿼리할 수 있는 데이터 포인트 수를 나타냅니다. 이러한 한도는 사용 중인 [데이터 옵션](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-prices) 에 따라 다릅니다.
-### 검사된 이벤트 제한에 포함되는 것은 무엇입니까? [#define-inspected-count]
+### 검사 횟수에 포함되는 것은 무엇입니까? [#what-counts-inspected-count]
-다음은 검사된 수 제한에 포함되고 제한에 도달하면 영향을 받는 기능 및 작업입니다. 다음 기간에 횟수가 제한 아래로 떨어지면 제한이 제거됩니다.
+다음 작업은 New Relic 계정의 검사 개수 제한에 포함됩니다.
* 사용자가 시작한 선별된 보기 로드(예:
- UI 페이지, 분산 추적 UI, 브라우저 모니터링 UI 페이지 또는 조직에 대한 데이터를 반환하는 모든 UI).
+ UI 페이지, 분산 추적 UI 또는 조직에 대한 데이터를 반환하는 모든 UI).
+
+* UI에서든 API를 통해든 New Relic 사용자가 실행하는 사용자 지정 쿼리입니다.
-* New Relic 사용자(NRQL 또는 NerdGraph)가 실행하는 사용자 정의 쿼리.
+* 사용자 정의 대시보드에서 쿼리를 실행하는 위젯 로드
-* 쿼리를 실행하는 사용자 정의 대시보드의 위젯.
+경고 조건 평가 및 알림은 제한에 포함되지 **않지만** 경고 알림에 포함된 New Relic에 대한 링크는 제한에 포함됩니다.
-* 경고 조건 평가 및 알림은 제한에 포함되지 **않지만** 경고 알림에 포함된 New Relic에 대한 링크는 제한에 포함됩니다.
+검사된 개수 제한에 도달하면 언급된 기능이 영향을 받습니다. 다음 기간에 개수가 한도 아래로 떨어지면 모든 제한 사항이 제거됩니다.
-### 쿼리 기간 제한 [#query-duration]
+## 쿼리 기간 제한 [#query-duration]
-쿼리 기간 제한은 NRQL 쿼리가 실행을 중지하기 전에 실행할 수 있는 시간입니다. 이 제한은 [데이터 옵션](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-prices) 에 따라 다릅니다.
+쿼리 기간 제한은 NRQL 쿼리가 실행을 중지하고 오류로 간주되기 전까지 실행할 수 있는 기간입니다. 이 한도는 [데이터 옵션](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing#data-prices) 에 따라 다릅니다.
* 원본 데이터 옵션: 1분
* 데이터 플러스:
- * 일반 NRQL 쿼리로 2분
- * [비동기 쿼리](/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial) 를 사용하여 10분
\ No newline at end of file
+ * 10분( [쿼리 빌더](/docs/query-your-data/explore-query-data/query-builder/introduction-query-builder) 또는 [NerdGraph](/docs/apis/nerdgraph/examples/async-queries-nrql-tutorial) 사용)
+ * 쿼리 빌더 이외의 다른 UI 위치에서 2분
+
+## 쿼리 수 제한 [#query-count-limits]
+
+이 제한은 API를 통해 실행되는 NRQL 쿼리에만 적용되며 UI에서 실행되는 쿼리에는 적용되지 않습니다.
+
+이 한도는 계정당 분당 3,000개의 쿼리입니다. 이 제한을 초과하면 쿼리 수가 더 이상 제한을 초과하지 않을 때까지 쿼리가 거부될 수 있습니다.
\ No newline at end of file
diff --git a/src/i18n/content/kr/docs/service-level-management/create-slm.mdx b/src/i18n/content/kr/docs/service-level-management/create-slm.mdx
index b35b2107168..9259e4462b7 100644
--- a/src/i18n/content/kr/docs/service-level-management/create-slm.mdx
+++ b/src/i18n/content/kr/docs/service-level-management/create-slm.mdx
@@ -134,7 +134,7 @@ SLI는 유효한 요청의 총 수에서 좋은 응답의 비율로 정의됩니
```sql
FROM: TransactionError
- WHERE: entityGuid = '{entityGuid}' AND error.expected IS FALSE
+ WHERE: entityGuid = '{entityGuid}' AND error.expected != true
```
여기서 `{entityGuid}` 은 서비스의 GUID입니다.