Replace DaprID with AppID (#500)

This commit is contained in:
Ricardo Niepel 2020-04-06 19:57:51 +02:00 committed by GitHub
parent 0107243f29
commit c4958949d2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 15 additions and 15 deletions

View File

@ -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"

View File

@ -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.

View File

@ -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:

View File

@ -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:

View File

@ -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:

View File

@ -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"

View File

@ -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)"
...

View File

@ -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`.

View File

@ -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