Skip to content
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.

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

Set span status according to Semantic Conventions of Http #164

Merged
merged 5 commits into from
Jun 1, 2022

Conversation

@gnm444 gnm444 requested a review from DebajitDas as a code owner May 24, 2022 10:41
@gnm444 gnm444 requested a review from a team May 24, 2022 10:41
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented May 24, 2022

CLA Signed

The committers listed above are authorized under a signed CLA.

@DebajitDas DebajitDas requested a review from kpratyus May 24, 2022 10:51
enum class SpanType {
INTERNAL,
SERVER,
CLIENT
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have SpanKind defined in ISdkWrapper. Any Challenge in re-using that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since they are in ISdkWrapper.h, including that in this header file is leading to circular inclusions. So avoided it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ISdkWrapper is the parent right? Why would there be a problem of circular inclusion?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved them to a new file to avoid circular inclusion



namespace appd {
namespace core {

#define HTTP_ERROR_1XX 100
#define HTTP_ERROR_4XX 400
#define HTTP_ERROR_5XX 500
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a discussion, Is it not better to use constexpr instead ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes Const is better. I will change to const int.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or we can use constexpr https://en.cppreference.com/w/cpp/language/constexpr as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3 defines look a little clumsy. Should we use a different data structure(like a struct)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed this by using constexpr in SdkConstants.h


} // sdkwrapper
} // core
} // appd
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a newline

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

interactionSpan->SetStatus(sdkwrapper::StatusCode::Unset);
}
else if (payload->errorCode >= HTTP_ERROR_4XX && payload->errorCode < HTTP_ERROR_5XX ) {
if (interactionSpan->GetSpanKind() == sdkwrapper::SpanType::SERVER)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DebajitDas just a question. The error and status code should be once for the whole request processing phase. Do we need to set the status for every span?

@@ -32,6 +32,7 @@ ScopedSpan::ScopedSpan(
options.kind = kind;
mSpan = sdkHelperFactory->GetTracer()->StartSpan(name, attributes, options);
mScope.reset(new trace::Scope(mSpan));
mSpanKind = kind;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need mSpanKind if we have options.kind?

@@ -68,6 +68,12 @@ void ServerSpan::SetStatus(const StatusCode status, const std::string& desc)
mScopedSpan->SetStatus(status, desc);
}

SpanType ServerSpan::GetSpanKind()
{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although the logic is correct, should we refactor the code in a way that both Serverspan and scopedspan have similar implementation for get span kind? This would be good for future as well


virtual void SetStatus(const StatusCode status, const std::string& desc = "") = 0;
virtual SpanType GetSpanKind() = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is SpanType same as trace::SpanKind?

@DebajitDas DebajitDas self-requested a review May 31, 2022 12:22
Copy link
Member

@DebajitDas DebajitDas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@DebajitDas
Copy link
Member

LGTM, will merge once Pratyush approves as well

@DebajitDas DebajitDas merged commit d1b9c1e into open-telemetry:main Jun 1, 2022
DebajitDas added a commit that referenced this pull request Jun 2, 2022
* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

Co-authored-by: Narasimha <ngonapa@cisco.com>
DebajitDas added a commit that referenced this pull request Jun 2, 2022
* Set span status according to Semantic Conventions of Http (#164)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

* Fixed UT failure  (#171)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

* Fixed unit test failure

Co-authored-by: Narasimha <ngonapa@cisco.com>
DebajitDas added a commit that referenced this pull request Jun 21, 2022
* Set span status according to Semantic Conventions of Http (#164)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

* Fixed UT failure  (#171)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

* Fixed unit test failure

Co-authored-by: Narasimha <ngonapa@cisco.com>
DebajitDas added a commit that referenced this pull request Jul 4, 2022
* Added dependencies of Nginx Build (#158)

* updated nginx build directory (#159)

* nginx source code (#160)

* Add license (#162)

* Add license

* removing Ubuntu condition

* Nomenclature changes from Appdynamics to OpenTelemetry (#163)

* Changed appd to otel

* Added build command for Nginx Module

* Added a missing file to be built

* Incorporated Review comments

* Nginx docker (#167)

* Changing docker compose

* centos7

* Updated README for Nginx instrumentation (#168)

* Updated README for Nginx instrumentation

* Updated README.md

* Updated README.md

* Set span status according to Semantic Conventions of Http (#164) (#169)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

Co-authored-by: Narasimha <ngonapa@cisco.com>

* Updated error codes (#170)

* Merged from Main branch (#172)

* Set span status according to Semantic Conventions of Http (#164)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

* Fixed UT failure  (#171)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

* Fixed unit test failure

Co-authored-by: Narasimha <ngonapa@cisco.com>

* Merge from main (#181)

* Set span status according to Semantic Conventions of Http (#164)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

* Fixed UT failure  (#171)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

* Fixed unit test failure

Co-authored-by: Narasimha <ngonapa@cisco.com>

Co-authored-by: DEBAJIT DAS <85024550+DebajitDas@users.noreply.github.com>
Co-authored-by: Narasimha <ngonapa@cisco.com>
kpratyus added a commit that referenced this pull request Jul 15, 2022
…cation. (#174)

* Added dependencies of Nginx Build (#158)

* updated nginx build directory (#159)

* nginx source code (#160)

* Add license (#162)

* Add license

* removing Ubuntu condition

* Nomenclature changes from Appdynamics to OpenTelemetry (#163)

* Changed appd to otel

* Added build command for Nginx Module

* Added a missing file to be built

* Incorporated Review comments

* Nginx docker (#167)

* Changing docker compose

* centos7

* Updated README for Nginx instrumentation (#168)

* Updated README for Nginx instrumentation

* Updated README.md

* Updated README.md

* Set span status according to Semantic Conventions of Http (#164) (#169)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

Co-authored-by: Narasimha <ngonapa@cisco.com>

* Updated error codes (#170)

* Merged from Main branch (#172)

* Set span status according to Semantic Conventions of Http (#164)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

* Fixed UT failure  (#171)

* Set span status according to http semantics

* Set span status changes part-2

* Set span status according to http semantics spaces

* Review comments addressed for span status

* Moved error status from Apache hooks to Request processing engine

* Fixed unit test failure

Co-authored-by: Narasimha <ngonapa@cisco.com>

* Handling span creation/end on Nginx internal redirection and named location, related to bug WEBSRV-721

* Fix for try files modules

* Added minor changes

* Incorporated some review comments

Co-authored-by: Kumar Pratyush <95214718+kpratyus@users.noreply.github.com>
Co-authored-by: Narasimha <ngonapa@cisco.com>
@marcalff marcalff added the Webserver This represents the otel-webserver-module in the instrumentation directory label May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Webserver This represents the otel-webserver-module in the instrumentation directory
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants