mirror of https://github.com/dapr/docs.git
Replace DaprID with AppID (#500)
This commit is contained in:
parent
0107243f29
commit
c4958949d2
|
@ -51,7 +51,7 @@ dapr run node myapp.js
|
|||
== DAPR == time="2019-09-05T12:26:43-07:00" level=info msg="starting Dapr Runtime -- version 0.3.0-alpha -- commit b6f2810-dirty"
|
||||
== DAPR == time="2019-09-05T12:26:43-07:00" level=info msg="log level set to: info"
|
||||
== DAPR == time="2019-09-05T12:26:43-07:00" level=info msg="standalone mode configured"
|
||||
== DAPR == time="2019-09-05T12:26:43-07:00" level=info msg="dapr id: Trackgreat-Lancer"
|
||||
== DAPR == time="2019-09-05T12:26:43-07:00" level=info msg="app id: Trackgreat-Lancer"
|
||||
== DAPR == time="2019-09-05T12:26:43-07:00" level=info msg="loaded component statestore (state.redis)"
|
||||
== DAPR == time="2019-09-05T12:26:43-07:00" level=info msg="loaded component messagebus (pubsub.redis)"
|
||||
== DAPR == 2019/09/05 12:26:43 redis: connecting to localhost:6379
|
||||
|
@ -123,7 +123,7 @@ kubectl logs addapp-74b57fb78c-67zm6 -c daprd
|
|||
time="2019-09-04T02:52:27Z" level=info msg="starting Dapr Runtime -- version 0.3.0-alpha -- commit b6f2810-dirty"
|
||||
time="2019-09-04T02:52:27Z" level=info msg="log level set to: info"
|
||||
time="2019-09-04T02:52:27Z" level=info msg="kubernetes mode configured"
|
||||
time="2019-09-04T02:52:27Z" level=info msg="dapr id: addapp"
|
||||
time="2019-09-04T02:52:27Z" level=info msg="app id: addapp"
|
||||
time="2019-09-04T02:52:27Z" level=info msg="application protocol: http. waiting on port 6000"
|
||||
time="2019-09-04T02:52:27Z" level=info msg="application discovered on port 6000"
|
||||
time="2019-09-04T02:52:27Z" level=info msg="actor runtime started. actor idle timeout: 1h0m0s. actor scan interval: 30s"
|
||||
|
|
|
@ -5,7 +5,7 @@ Observability is a term from control theory. Observability means you can answer
|
|||
The observability capabilities enable users to monitor the Dapr system services, their interaction with user applications and understand how these monitored services behave. The observability capabilities are divided into the following areas;
|
||||
|
||||
* **[Metrics](./metrics.md)**: are the series of measured values and counts that are collected and stored over time. Dapr metrics provide monitoring and understanding of the behavior of Dapr system services and user apps. For example, the service metrics between Dapr sidecars and user apps show call latency, traffic failures, error rates of requests etc. Dapr system services metrics show side car injection failures, health of the system services including CPU usage, number of actor placement made etc.
|
||||
* **[Logs](./logs.md)**: are records of events that occur occur that can be used to determine failures or other status. Logs events contain warning, error, info and debug messages produced by Dapr system services. Each log event includes metadata such as message type, hostname, component name, Dapr id, ip address, etc.
|
||||
* **[Logs](./logs.md)**: are records of events that occur occur that can be used to determine failures or other status. Logs events contain warning, error, info and debug messages produced by Dapr system services. Each log event includes metadata such as message type, hostname, component name, App ID, ip address, etc.
|
||||
* **[Distributed tracing](./traces.md)**: is used to profile and monitor Dapr system services and user apps. Distributed tracing helps pinpoint where failures occur and what causes poor performance. Distributed tracing is particularly well-suited to debugging and monitoring distributed software architectures, such as microservices. You can use distributed tracing to help debug and optimize application code. Distributed tracing contains trace spans between the Dapr runtime, Dapr system services, and user apps across process, nodes, network, and security boundaries. It provides a detailed understanding of service invocations (call flows) and service dependencies.
|
||||
* **[Health](./health.md)**: Dapr provides a way for a hosting platform to determine it's health using an HTTP endpoint. With this endpoint, the Dapr process, or sidecar, can be probed to determine its readiness and liveness and action taken accordingly.
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ The easiest way to connect to your Cosmos DB instance is to use the Data Explore
|
|||
|
||||
> **NOTE:** The following samples use Cosmos DB [SQL API](https://docs.microsoft.com/en-us/azure/cosmos-db/sql-query-getting-started). When you configure an Azure Cosmos DB for Dapr, you need to specify the exact database and collection to use. The follow samples assume you've already connected to the right database and a collection named "states".
|
||||
|
||||
## 2. List keys by Dapr id
|
||||
## 2. List keys by App ID
|
||||
|
||||
To get all state keys associated with application "myapp", use the query:
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@ You can use the official [redis-cli](https://redis.io/topics/rediscli) or any ot
|
|||
docker run --rm -it --link <name of the Redis container> redis redis-cli -h <name of the Redis container>
|
||||
```
|
||||
|
||||
## 2. List keys by Dapr id
|
||||
## 2. List keys by App ID
|
||||
|
||||
To get all state keys associated with application "myapp", use the command:
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@ The easiest way to connect to your SQL Server instance is to use the [Azure Data
|
|||
|
||||
> **NOTE:** The following samples use Azure SQL. When you configure an Azure SQL database for Dapr, you need to specify the exact table name to use. The follow samples assume you've already connected to the right database with a table named "states".
|
||||
|
||||
## 2. List keys by Dapr id
|
||||
## 2. List keys by App ID
|
||||
|
||||
To get all state keys associated with application "myapp", use the query:
|
||||
|
||||
|
|
|
@ -220,7 +220,7 @@ In Kubernetes mode, you store the certificate for the service principal into the
|
|||
time="2020-02-05T09:15:03Z" level=info msg="starting Dapr Runtime -- version edge -- commit v0.3.0-rc.0-58-ge540a71-dirty"
|
||||
time="2020-02-05T09:15:03Z" level=info msg="log level set to: info"
|
||||
time="2020-02-05T09:15:03Z" level=info msg="kubernetes mode configured"
|
||||
time="2020-02-05T09:15:03Z" level=info msg="dapr id: nodeapp"
|
||||
time="2020-02-05T09:15:03Z" level=info msg="app id: nodeapp"
|
||||
time="2020-02-05T09:15:03Z" level=info msg="mTLS enabled. creating sidecar authenticator"
|
||||
time="2020-02-05T09:15:03Z" level=info msg="trust anchors extracted successfully"
|
||||
time="2020-02-05T09:15:03Z" level=info msg="authenticator created"
|
||||
|
|
|
@ -281,7 +281,7 @@ $ kubectl logs nodeapp-f7b7576f4-4pjrj daprd
|
|||
time="2019-09-26T20:34:23Z" level=info msg="starting Dapr Runtime -- version 0.4.0-alpha.4 -- commit 876474b-dirty"
|
||||
time="2019-09-26T20:34:23Z" level=info msg="log level set to: info"
|
||||
time="2019-09-26T20:34:23Z" level=info msg="kubernetes mode configured"
|
||||
time="2019-09-26T20:34:23Z" level=info msg="dapr id: nodeapp"
|
||||
time="2019-09-26T20:34:23Z" level=info msg="app id: nodeapp"
|
||||
time="2019-09-26T20:34:24Z" level=info msg="loaded component azurekeyvault (secretstores.azure.keyvault)"
|
||||
time="2019-09-26T20:34:25Z" level=info msg="loaded component statestore (state.redis)"
|
||||
...
|
||||
|
|
|
@ -740,12 +740,12 @@ In order to enable visibility into the state of an actor and allow for complex s
|
|||
|
||||
The state namespace created by Dapr for actors is composed of the following items:
|
||||
|
||||
* Dapr ID - Represents the unique ID given to the Dapr application.
|
||||
* App ID - Represents the unique ID given to the Dapr application.
|
||||
* Actor Type - Represents the type of the actor.
|
||||
* Actor ID - Represents the unique ID of the actor instance for an actor type.
|
||||
* Key - A key for the specific state value. An actor ID can hold multiple state keys.
|
||||
|
||||
The following example shows how to construct a key for the state of an actor instance under the `myapp` Dapr ID namespace:
|
||||
The following example shows how to construct a key for the state of an actor instance under the `myapp` App ID namespace:
|
||||
`myapp-cat-hobbit-food`
|
||||
|
||||
In the example above, we are getting the value for the state key `food`, for the actor ID `hobbit` with an actor type of `cat`, under the Dapr ID namespace of `myapp`.
|
||||
In the example above, we are getting the value for the state key `food`, for the actor ID `hobbit` with an actor type of `cat`, under the App ID namespace of `myapp`.
|
||||
|
|
|
@ -40,13 +40,13 @@ Please refer https://github.com/dapr/dapr/blob/master/docs/decision_records/api/
|
|||
Dapr state stores are key/value stores. To ensure data compatibility, Dapr requires these data stores follow a fixed key scheme. For general states, the key format is:
|
||||
|
||||
```
|
||||
<Dapr id>||<state key>
|
||||
<App ID>||<state key>
|
||||
```
|
||||
|
||||
For Actor states, the key format is:
|
||||
|
||||
```
|
||||
<Dapr id>||<Actor type>||<Actor id>||<state key>
|
||||
<App ID>||<Actor type>||<Actor id>||<state key>
|
||||
```
|
||||
|
||||
## Save state
|
||||
|
@ -245,8 +245,8 @@ spec:
|
|||
|
||||
A Dapr-compatible state store shall use the following key scheme:
|
||||
|
||||
* *\<Dapr id>||\<state key>* key format for general states
|
||||
* *\<Dapr id>||\<Actor type>||\<Actor id>||\<state key>* key format for Actor states.
|
||||
* *\<App ID>||\<state key>* key format for general states
|
||||
* *\<App ID>||\<Actor type>||\<Actor id>||\<state key>* key format for Actor states.
|
||||
|
||||
### Concurrency
|
||||
|
||||
|
|
Loading…
Reference in New Issue