Skip to content

Fix pipes in tables where possible #27622

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 17, 2021
Merged

Fix pipes in tables where possible #27622

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions docs/architecture/dapr-for-net-developers/observability.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ Dapr provides [collectors](https://docs.dapr.io/operations/monitoring/tracing/op

1. Service A calls an operation on Service B. The call is routed from a Dapr sidecar for Service A to a sidecar for Service B.
1. When Service B completes the operation, a response is sent back to Service A through the Dapr sidecars. They gather and publish all available telemetry for every request and response.
1. The configured collector ingests the telemetry and sends it to the monitoring back end.
1. The configured collector ingests the telemetry and sends it to the monitoring back end.

As a developer, keep in mind that adding observability is different from configuring other Dapr building blocks, like pub/sub or state management. Instead of referencing a building block, you add a collector and a monitoring back end. Figure 10-1 shows it's possible to configure multiple collectors that integrate with different monitoring back ends.

Expand All @@ -62,7 +62,7 @@ Dapr uses the [W3C Trace Context](https://www.w3.org/TR/trace-context) to correl
**Figure 10-2**. W3C Trace Context example.

1. Service A invokes an operation on Service B. As Service A starts the call, Dapr creates a unique trace context and injects it into the request.
1. Service B receives the request and invokes an operation on Service C. Dapr detects that the incoming request contains a trace context and propagates it by injecting it into the outgoing request to Service C.
1. Service B receives the request and invokes an operation on Service C. Dapr detects that the incoming request contains a trace context and propagates it by injecting it into the outgoing request to Service C.
1. Service C receives the request and handles it. Dapr detects that the incoming request contains a trace context and propagates it by injecting it into the outgoing response back to Service B.
1. Service B receives the response and handles it. It then creates a new response and propagates the trace context by injecting it into the outgoing response back to Service A.

Expand Down Expand Up @@ -271,7 +271,7 @@ Metrics provide insight into performance and resource consumption. Under the hoo

**Figure 10-8**. Scraping Prometheus metrics.

Each sidecar and system service exposes a metric endpoint that listens on port 9090. The Prometheus Metrics Scrapper captures metrics from each endpoint and published the information to the monitoring back end.
Each sidecar and system service exposes a metric endpoint that listens on port 9090. The Prometheus Metrics Scrapper captures metrics from each endpoint and published the information to the monitoring back end.

#### Service discovery

Expand Down Expand Up @@ -325,7 +325,7 @@ The Dapr documentation includes a [tutorial for installing Prometheus and Grafan

### Logging

Logging provides insight into what is happening with a service at run time. When running an application, Dapr automatically emits log entries from Dapr sidecars and Dapr system services. However, logging entries instrumented in your application code **aren't** automatically included. To emit logging from application code, you can import a specific SDK like [OpenTelemetry SDK for .NET](https://opentelemetry.io/docs/net/). Logging application code is covered later in this chapter in the section *Using the Dapr .NET SDK*.
Logging provides insight into what is happening with a service at run time. When running an application, Dapr automatically emits log entries from Dapr sidecars and Dapr system services. However, logging entries instrumented in your application code **aren't** automatically included. To emit logging from application code, you can import a specific SDK like [OpenTelemetry SDK for .NET](https://opentelemetry.io/docs/net/). Logging application code is covered later in this chapter in the section *Using the Dapr .NET SDK*.

#### Log entry structure

Expand All @@ -334,7 +334,7 @@ Dapr emits structured logging. Each log entry has the following format:
| Field | Description | Example |
| -------- | ------------------------------------------------------------ | ----------------------------------- |
| time | ISO8601 formatted timestamp | `2021-01-10T14:19:31.000Z` |
| level | Level of the entry (`debug` \| `info` \| `warn` \| `error`) | `info` |
| level | Level of the entry (`debug`, `info`, `warn`, or `error`) | `info` |
| type | Log Type | `log` |
| msg | Log Message | `metrics server started on :62408/` |
| scope | Logging Scope | `dapr.runtime` |
Expand Down
72 changes: 36 additions & 36 deletions docs/core/diagnostics/dotnet-dump.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -142,42 +142,42 @@ dotnet-dump analyze <dump_path> [-h|--help] [-c|--command]

### Analyze SOS commands

| Command | Function |
| ----------------------------------- | --------------------------------------------------------------------------------------------- |
| `soshelp|help` | Displays all available commands |
| `soshelp|help <command>` | Displays the specified command. |
| `exit|quit` | Exits interactive mode. |
| `clrstack <arguments>` | Provides a stack trace of managed code only. |
| `clrthreads <arguments>` | Lists the managed threads running. |
| `dumpasync <arguments>` | Displays information about async state machines on the garbage-collected heap. |
| `dumpassembly <arguments>` | Displays details about the assembly at the specified address. |
| `dumpclass <arguments>` | Displays information about the `EEClass` structure at the specified address. |
| `dumpdelegate <arguments>` | Displays information about the delegate at the specified address. |
| `dumpdomain <arguments>` | Displays information all the AppDomains and all assemblies within the specified domain. |
| `dumpheap <arguments>` | Displays info about the garbage-collected heap and collection statistics about objects. |
| `dumpil <arguments>` | Displays the Microsoft intermediate language (MSIL) that is associated with a managed method. |
| `dumplog <arguments>` | Writes the contents of an in-memory stress log to the specified file. |
| `dumpmd <arguments>` | Displays information about the `MethodDesc` structure at the specified address. |
| `dumpmodule <arguments>` | Displays information about the module at the specified address. |
| `dumpmt <arguments>` | Displays information about the `MethodTable` at the specified address. |
| `dumpobj <arguments>` | Displays info about the object at the specified address. |
| `dso|dumpstackobjects <arguments>` | Displays all managed objects found within the bounds of the current stack. |
| `eeheap <arguments>` | Displays info about process memory consumed by internal runtime data structures. |
| `finalizequeue <arguments>` | Displays all objects registered for finalization. |
| `gcroot <arguments>` | Displays info about references (or roots) to the object at the specified address. |
| `gcwhere <arguments>` | Displays the location in the GC heap of the argument passed in. |
| `ip2md <arguments>` | Displays the `MethodDesc` structure at the specified address in JIT code. |
| `histclear <arguments>` | Releases any resources used by the family of `hist*` commands. |
| `histinit <arguments>` | Initializes the SOS structures from the stress log saved in the debuggee. |
| `histobj <arguments>` | Displays the garbage collection stress log relocations related to `<arguments>`. |
| `histobjfind <arguments>` | Displays all the log entries that reference the object at the specified address. |
| `histroot <arguments>` | Displays information related to both promotions and relocations of the specified root. |
| `lm|modules` | Displays the native modules in the process. |
| `name2ee <arguments>` | Displays the `MethodTable` and `EEClass` structures for the `<argument>`. |
| `pe|printexception <arguments>` | Displays any object derived from the <xref:System.Exception> class for the `<argument>`. |
| `setsymbolserver <arguments>` | Enables the symbol server support |
| `syncblk <arguments>` | Displays the SyncBlock holder info. |
| `threads|setthread <threadid>` | Sets or displays the current thread ID for the SOS commands. |
| Command | Function |
|-----------------------------------------------------|-----------------------------------------------------------------------------------------------|
| `soshelp` or `help` | Displays all available commands |
| `soshelp <command>` or `help <command>` | Displays the specified command. |
| `exit` or `quit` | Exits interactive mode. |
| `clrstack <arguments>` | Provides a stack trace of managed code only. |
| `clrthreads <arguments>` | Lists the managed threads running. |
| `dumpasync <arguments>` | Displays information about async state machines on the garbage-collected heap. |
| `dumpassembly <arguments>` | Displays details about the assembly at the specified address. |
| `dumpclass <arguments>` | Displays information about the `EEClass` structure at the specified address. |
| `dumpdelegate <arguments>` | Displays information about the delegate at the specified address. |
| `dumpdomain <arguments>` | Displays information all the AppDomains and all assemblies within the specified domain. |
| `dumpheap <arguments>` | Displays info about the garbage-collected heap and collection statistics about objects. |
| `dumpil <arguments>` | Displays the Microsoft intermediate language (MSIL) that is associated with a managed method. |
| `dumplog <arguments>` | Writes the contents of an in-memory stress log to the specified file. |
| `dumpmd <arguments>` | Displays information about the `MethodDesc` structure at the specified address. |
| `dumpmodule <arguments>` | Displays information about the module at the specified address. |
| `dumpmt <arguments>` | Displays information about the `MethodTable` at the specified address. |
| `dumpobj <arguments>` | Displays info about the object at the specified address. |
| `dso <arguments>` or `dumpstackobjects <arguments>` | Displays all managed objects found within the bounds of the current stack. |
| `eeheap <arguments>` | Displays info about process memory consumed by internal runtime data structures. |
| `finalizequeue <arguments>` | Displays all objects registered for finalization. |
| `gcroot <arguments>` | Displays info about references (or roots) to the object at the specified address. |
| `gcwhere <arguments>` | Displays the location in the GC heap of the argument passed in. |
| `ip2md <arguments>` | Displays the `MethodDesc` structure at the specified address in JIT code. |
| `histclear <arguments>` | Releases any resources used by the family of `hist*` commands. |
| `histinit <arguments>` | Initializes the SOS structures from the stress log saved in the debuggee. |
| `histobj <arguments>` | Displays the garbage collection stress log relocations related to `<arguments>`. |
| `histobjfind <arguments>` | Displays all the log entries that reference the object at the specified address. |
| `histroot <arguments>` | Displays information related to both promotions and relocations of the specified root. |
| `lm` or `modules` | Displays the native modules in the process. |
| `name2ee <arguments>` | Displays the `MethodTable` and `EEClass` structures for the `<argument>`. |
| `pe <arguments>` or `printexception <arguments>` | Displays any object derived from the <xref:System.Exception> class for the `<argument>`. |
| `setsymbolserver <arguments>` | Enables the symbol server support |
| `syncblk <arguments>` | Displays the SyncBlock holder info. |
| `threads <threadid>` or `setthread <threadid>` | Sets or displays the current thread ID for the SOS commands. |

> [!NOTE]
> Additional details can be found in [SOS Debugging Extension for .NET](sos-debugging-extension.md).
Expand Down
2 changes: 1 addition & 1 deletion docs/core/tools/custom-templates.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ The *template.json* file is placed in a *.template.config* folder in the root di
| ----------------- | ------------- | ----------- |
| `$schema` | URI | The JSON schema for the *template.json* file. Editors that support JSON schemas enable JSON-editing features when the schema is specified. For example, [Visual Studio Code](https://code.visualstudio.com/) requires this member to enable IntelliSense. Use a value of `http://json.schemastore.org/template`. |
| `author` | string | The author of the template. |
| `classifications` | array(string) | Zero or more characteristics of the template that a user might use to find the template when searching for it. The classifications also appear in the *Tags* column when it appears in a list of templates produced by using the `dotnet new -l|--list` command. |
| `classifications` | array(string) | Zero or more characteristics of the template that a user might use to find the template when searching for it. The classifications also appear in the *Tags* column when it appears in a list of templates produced by using the `dotnet new -l` or `dotnet new --list` command. |
| `identity` | string | A unique name for this template. |
| `name` | string | The name for the template that users should see. |
| `shortName` | string | A default shorthand name for selecting the template that applies to environments where the template name is specified by the user, not selected via a GUI. For example, the short name is useful when using templates from a command prompt with CLI commands. |
Expand Down
Loading