-
Notifications
You must be signed in to change notification settings - Fork 306
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
Add logs listing feature #622
Add logs listing feature #622
Conversation
This commit implemented API wrapper of 'logs-queries/list' (c.f. https://docs.datadoghq.com/api/v1/logs/) that returns list of logs which are mached with specified log query.
Hi, This is already handled by our generated client: https://github.com/DataDog/datadog-api-client-python/blob/master/docs/v1/LogsApi.md#list_logs Would that work for your purpose? |
@therve But I'm not only interested in using this feature, but I want to use a software that depends on datadogpy. BTW, I wonder why Datadog team develops two different Python libraries. Will this (datadogpy) not be extended any more and be obsoleted? |
It's tough to keep up manually with all the APIs we produce, so we started a new generated library.
datadogpy will continue to live, as it contains other capabilities (like metrics and dogstatsd) that our generated library doesn't do. We're still trying to define what our strategy is going to be, but we'll most likely won't add new endpoints to datadogpy like this one. One possibility would be to depend on datadog-api-client-python and expose the functionality that way, would that work for you? |
Thank you for answering my question. May I ask some more questions? I wonder what we should do in the use-case that datadog user wants to use both logs and metrics API simultaneously(e.g. posting metric that is made from collected logs). Should we have to use both datadogpy and datadog-api-client-python libraries in our software? And as you said, the datadog-api-client-python seems not to have implementation to handle some metrics APIs (e.g. [POST] /api/v1/series). |
Today, yes. As mentioned previously, one possible implementation is to import datadog-api-client-python in datadogpy, so that you only depend and use datadogpy, but it uses datadog-api-client-python under the hood. Today you have to use both.
No we don't plan to add metric submission to generated clients. |
Thank you for your reply. Sorry, I'm not sure the meaning of "Today". If you don't plan to support metrics API on the datadog-api-client-python. User permanently has to use both libraries for that use-case, doesn't it? Or, is there possibility to consider to merge a PR when I make another PR that implement API handler of metrics on the datadog-api-client-python like this? |
User has to install both, but we can make it so that you only explicitly depend on and import datadogpy.
No we won't accept such a contribution. We might at some point add it, but it would be generated anyway. |
Sorry, I had insufficient understanding about what the difference between datadogpy and datadog-api-client-python. To summarize, the datadogpy is a traditional datadog python library and it has been extended in manual. On the other hand, the datadog-api-client-python is another python API client for the Datadog API. Thats code is generated using some other tools. And it is expected to collect all public Datadog API endpoints, but it has not finished it yet, right? I think the datadog-api-client-python is elaborate and cool solution. And I also understood the reason why it won't accept this type of in manual extended because that code would be generated automatically.
I know that feeling, but I suspect whether this bold decision is good for Datadog users. I suggest to keep maintaining (including extending features) datadogpy until the datadog-api-client-python has been completed. Following is reasons why I think so. (reason1) It causes an inconvenience for usersIf the datadog-api-client-python has already cover all the Datadog API, I'll be all for that decision. But it hasn't yet. If you make a decision that datadogpy refuse any kind extension any more, user might feel that "Both official python libraries are useless. One has abandoned extending of features, some API endpoints have not been supported. And another is in the middle of development, some API endpoints also have not been supported yet". User carefully has to distinguish which library should we use depending on what API endpoints user want to access. This is inconvenient for users I think. (reason2) Probably no one knows itI've read the whole datadogpy README and an official documentation that describes client libraries. There is no explanation that the datadogpy intends not to develop extensions and accept any PR that extends feature any more. This is against for users expectation I think. I understand how you feel that you want to dedicate to developing the datadog-api-client-python. But please at least accept contributions for the datadogpy from user if it's worth for users until development of the datadog-api-client-python is finished. I hope Datadog team makes a decision that makes Datadog users happy. Sincerely, |
I didn't say we won't accept your patch. I said we already have a library which does what you need. If the plan isn't clear it's because it's not finalized. We'll clarify the place of both libraries when it is. Thanks. |
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
Requirements for Contributing to this repository
What does this PR do?
This PR implement a feature which is mentioned at #611.
Description of the Change
This PR implemented API wrapper of 'logs-queries/list' (c.f.
https://docs.datadoghq.com/api/v1/logs/) that returns list of logs which
are matched with specified log query.
Alternate Designs
This PR follows implementation of other API wrappers.
Possible Drawbacks
Yes. This PR has backward compatibility because this just add a new API wrapper.
Verification Process
This is an example code to get logs by using added implementation. If you run this code, please replace APP_KEY, API_KEY and SEARCH_QUERY for your environment.
Review checklist (to be filled by reviewers)
changelog/
label attached. If applicable it should have thebackward-incompatible
label attached.do-not-merge/
label attached.kind/
andseverity/
labels attached at least.